René Rebe

Apple just released the first macOS 10.13 “High Sierra” Beta. Actually I’m quite surprised of the lack of inspiration in naming. They switched from nice cat names, to boring California landmark names, only to go form Sierra to High Sierra? Is there nothing else more investing to name it? Also this results in rather poor google experience when you google for high sierra issues and one get’s overloaded with old Sierra stuff, … Maybe they are just too high in their Cupertino UFO spaceship these days, …

Anyways, the install experience, oh my, god, where should I even start. Why the heck can they not publish proper, good old installer disk images? And with this High Sierra Beta they reached a new sad point of annoyance. So first some “macOSDeveloperBetaAccessUtility.dmg” packages has to be downloaded (150k or so), after some system fiddling (btw, what exactly?) You get a “Install macOS 10.13 Beta.app” int the AppStore like with previous macOS versions. But instead of including all the installer image, it is only 5MB in size.

Starting that app does some Apple authorisation (again), think preventing Hackintosh’s, and then starts downloading the installer disk images into /macOS\ Install\ Data/, like InstallESDDmg.pkg.partial, and such.

So the problem will all this error prone steps is that the first time the download got stuck at some 4.8 GB. Restarting this stupid loader app wiped all the data and stated from scratch!!! :-/ So some hour and another 5GB wasted in the internet later, it rebooted the system just to tell me I would not have enough space. Wait what? It could not determine that before all the wasted time and data? And only offer to reboot, ..!

Guess what? At that point the f*cking installer thing again removed all the 5GB+ installer image from /macOS\ Install\ Data/ !!!!1!!!

So instead of me being able to plug in other external disk or whatever for installation. I now again need to wait an hour or two, and load the 5GB+ of data, again, and again.

Why do they have to re-implement this crappy, error prone downloader, when the App Store already has a download facility that may be more stable, continue stopped downloads and would also leave the installer image where it was for the next test install.

Each year the whole install procedure feel more like a hidden, user unfriendly labyrinth maze that you would expect from Microsoft in Windows, but not from a cleanly structured Unix kind of system we expect macOS to be.

Unfortunately it looks like Apple is giving up on this clean structure for the sake of making Hackintoshs harder thru obscurity.

Sad. Just so sad :-/

While traveling abroad the other day I needed to save bandwidth and download an SD video of an HD TV series season pass in iTunes. A long search of hidden easter eggs - but I finally found it:

Why do the companies need to change their UI so often, make things more difficult and hide in the least expected corners? Why can this not be simple, context options where one would expect it?

I got a nearly unused Oqo 01+ a few years ago for my vintage computer collection. You know, because it has “rare” Transmeta Efficeon cpu in it. As the original power supplies are apparently prone to fail, it already came without a power supply and I had to always use the lab supply on my desk (don’t ask, just the usual computer scientist office desk ;-)

Back in the day I found a bloodspot.com post form Ekawahyu Susilo, were he measured the pins - however, given the usual bitrot in the interwebs the post is now gone, and I peeled the most useful photo out of the archive.org to archive it prominently here as well:

(1) is VCC1, (2) is GND, and (3) is VCC2. Pin (4) is connected to GND and pin (5) is connected to VCC2. As far as I have found, VCC1 (5-6V?) is used for charging, while VCC2 (may be better lower at just 5V?) is used to directly run the Oqo, …

Update: now with video! ;-)

We just released a new application we were working on: re/compress 1.0 (or by our new versioning schema 17.1).

As I mentioned some years ago we have written a new PDF library from scratch for our portable port of OCRKit.

While we always simply wrote PDF ourselves, for reading PDF files we initially used macOS’ PDF framework. Until we ported OCRKit and ExactScan to Windows and Linux, too.

We could have simply find some open source code for that, but we ultimately decided against this. One benefit of knowing your own code is, that you can usually fix issues in a matter of minutes, instead of searching thru other people’s code for days or weeks. Customers are always amazed about our turn around time for bug reports, or on-site support ;-)

In the meantime we know PDFs inside out, and thru our involvement in the TWAIN Working Group even work with the PDF Association on some PDF standards. After having seen so many defect, non standard conforming, or simply not that compressed files in the wild at customers, we though: Why not factor out PDF optimization, recompression and error recovery into an own affordable App and started to work on re/compress.

Re/compress will go thru all the file’s objects, and re-writes them in the most compact and compressed way. If any recovery methods were needed to read defect or broken files, the new file will be written with all this corrections applied for other, regular PDF applications to be abel to read the file, too.

Additionally, for the big space savings, the images can be re-compressed, and optionally down-sampled to really reduce huge files to very lightweight ones for sharing, and mailing.

And best of all: Since we created our own cross-platform UI, re/compress is immediately available for Mac, Windows, and theoretically Linux, too (if you are interested in the later just drop us a note).

re/compress PDF.

This thing, when you buy a Teac HA-P50 for some Hi-Res Audio testing, and the matching iOS app (you know, for hi-res, FLAC and such, …, sigh) produces extremely audible clicks and pops that sounds like buffer under run / overflow / whatever - on a recent iPhone 6s no less.

What the heck are the vendor’s thinking to ship such crap to their premium paying customers?

Funny thing, other apps, such Apple’s own Music.app do not have this clicks and pops, … ???!!!

Judging from the App review an at least one year old problem:

PS: And why the heck do they sell the Teac HA-P50 for US$199 in the states, and for 299€ in Europe?

I took a closer look at the latest 32-bit DACs and wondered how much better they can be over other state of the art 24-bit DACs, so let’s take a quick look:

ESS9012: DNR: 133db, THD: 120dB - 32 bit
AK4497EQ: SNR: 128dB, THD: 116dB - 32 bit

compared to classic vendor’s 24-bit reference DACs:
CS5381: SNR: 120dB, THD: 110dB - 24 bit
WM8741: SNR: 125dB, THD: 100dB - 24 bit
PCM1792: SNR: 129db, THD: 128dB - 24 bit

and some more reference points:
vintage 1996 CS4328: SNR: 120db, THD: 93dB - 18 bit
PCM5102 (as in TEAC HA-P50): SNR: 112dB, 93dB - w/ 32-bit interf.?!

So they are not really much better than other state of the art reference DACs, e.g. the Cirrus Logic Crystal DAC, and the TI Burr Brown DAC has even mostly better spec? Hmm, …

And in case of the PCM5102 as used in the Teac HA-P50 portable headphone amp I am actually quite disappointed that it’s technical specs are not really better than a vintage, 1996 Cirrus Logic CS4328. Back in the day their state of the art reference DAC.

And what are the theoretically limits for 24 bit (simplified):

20*log10(2)*24 == 144dB

and for 32 bit:

20*log10(2)*32 == 192dB

So which theoretical limit are those DACs approaching?, …

I rather have an honest 24-bit DAC than a 32-bit marketing wanna be. And even the 1996 CS4328 already accepts surplus bits on the serial bus. So you could already call those “with 32-bit interface”, ..:-)

Update: Even more curious are the newer TI, Burr Brown chips:

PCM1792: SNR: 129db, THD: THD+N: 0.0004% - 24 bit
PCM1795: SNR: 123db, THD: THD+N: 0.0005% - 32 bit

Huh? Why has the Advanced Segment 2009 DAC worse spec than the 2004 one (beside consuming less power, …)?

Yesterday we were at Denis Matsuev, piano, live in Berlin.

#Berlin #denismatsuev #gendarmenmarkt

A photo posted by René Rebe (@renerebe) on Dec 19, 2016 at 11:43am PST

Given all the recent hi-fi testing I realized the Signal-to-Noise Ratio (SNR) in real life is actually not that great, …

…, with all the people moving, breathing, clothes fabric scratching and aircon ventilation, making some background hiss, …

…, plus in the Berlin winter all the coughing, …

and we talk here about some digital 24, or 32 bit 130dB+

ah, this bare to the bits uboot CLI, sigh:

mmcinit
ext2ls mmc 0
ext2load mmc 0:1 0×10400000 /uImage; bootm

fsload 0×10400000 boot/uImage
set bootargs ‘console=ttyS0 root=/dev/mtdblock1 rootfstype=jffs2′
bootm

saveenv

I am a longstanding fan of analog audio connectors, such as the headphone jack. During the iPhone7 rumors I long pointed out the many drawbacks of wireless audio: very lossy SBC -few combination support the also lossy aptX-, charging, connectivity issues etc.

While I still boycott the iPhones without headphone jack I run into the issue myself testing a Sennheiser Momemtum M2 Wireless the other weekend. Turns out on iOS Garageband does not use bluetooth by default, if you select it anyway, the App even warns about latency, and then if you actually use it iOS is such a degenerated crap, that it Garageband not allow you to use a Lightning connected audio input with Bluetooth audio out, … !!! What the heck?!?!

And when you do the Joe-user task of watching video? It is not even lip-sync anymore - the audio is seeable lagging like half a second or so, … !!!

Sad new wireless world :-/

In the 192kHz article I recently mentioned that Microsoft’s Surface Pro 3 with it’s ALC288 codec would max out at 48kHz. Turns out the Surface Pro 2 uses a ALC280 that surprisingly supports up to 192kHz. WTH?

/proc/asound/card1# grep rate codec#0
rates [0×5f0]: 32000 44100 48000 88200 96000 192000
rates [0×560]: 44100 48000 96000 192000
rates [0×560]: 44100 48000 96000 192000
rates [0×5f0]: 32000 44100 48000 88200 96000 192000
rates [0×560]: 44100 48000 96000 192000
rates [0×560]: 44100 48000 96000 192000