René Rebe

tcpdump -i eth0 -v ip6

Historically there was an Apple hardware test that you could boot to check if your Mac’s hardware is all good.

It came to a surprise though, that with newer Macs simply holding the ‘d’ during power on it runs some simple hardware diagnostic, too.

One should probably more often read Apple’s support pages, ..

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

Recently I spent some time finally finishing my DIY DAC and needed some signal generator for digital AES/EBU, coax / spdif audio to test and evaluate it. Turns out sox is pretty handy for that:

sox -r 48000 -n -t alsa spdif synth sine 1000 # square, triangle, sawtooth

Update:

sox infile.wav outfile-left.wav remix 1
sox infile.wav outfile.wav remix 1,2

If sox can not read your macOS recorded file with:

sox FAIL formats: can’t open input file Recodging.aifc: Unsupported AIFC compression type ‘in24′

You can let it use libsndfile to load the file anyway:

sox -t sndfile Recordings.aifc converted.aif

Update 2:

ffmpeg -i movie.mov -vn -acodec copy out.mp2

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 :-/