Recompress PDF 1.0 (aka 17.1)

February 1st, 2017

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.

TEAC HR Audio Player for iOS

January 5th, 2017

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?

Are 32-bit audio DACs any good?

December 31st, 2016

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, …)?

Real world, live, Signal-to-Noise Ratio

December 20th, 2016

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

#Berlin #denismatsuev #gendarmenmarkt

A photo posted by René Rebe (@renerebe) on

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+

[self note:@”u-boot”];

December 17th, 2016

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

Synthesizing audio with sox on Linux

December 6th, 2016

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

Bluetooth audio

December 6th, 2016

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

Bluez 5

November 6th, 2016

I only realize now, in good old Linux tradition the command-line-interface of Bluez 5 was totally renewed compared to what was used the last decade up to Bluez 4.

So instead of “hcitool scan” and such you now have to run all the commands in some command line interpreting shell, sigh:

$bluetoothctl

[bluetooth]#list

[bluetooth]#show controller_mac_address

[bluetooth]#select controller_mac_address

[bluetooth]#power on

[bluetooth]#agent on
[bluetooth]#default-agent

[bluetooth]#discoverable on
[bluetooth]#pairable on

[bluetooth]#scan on

Update: some more details

The older Surface 2 can play at 192kHz

November 5th, 2016

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

Random cloud changes

October 21st, 2016

For a while I already watched some other business struggling with workflow inefficiency by using cloud services that randomly (like monthly) change some user interface, options etc. and thus waste hours and hours of the time of workers to actually get their work done.

While we protect our data and investment by not using cloud services for anything productive (exception like Google Adwords, …) today we hit a similar issue. I automated invoice generation from our online store PayPal email notifications. Some days ago on October the 15th PayPal deviced out of the blue sky that it would probably be nice if they modernized their email templates.

Well, great for them, no so for our nicely script automated invoice generation. But even for the users:

Before the PayPal notifications where: Content-Type: multipart/alternative; with a Content-Type: text/plain; charset=UTF-8 and a Content-Type: text/html; charset=UTF-8 and about 20 kB in size.

Unix veterans could still nicely read the text/plain part in pine, mutt or wherever. The new emails did away with the text/plain part, and only send a Content-Type: text/html; charset=UTF-8 and the designers even blew that up to now consume a whooping 90kB.

Worst of all as of today they still send us a mix of old a new template based emails. Obviously awesome for some reliable processing, …

So this is what the silicon valley companies call progress? :-/

Update: Most of the size increase is actually mobile optimization CSS. WTF optimization is that? I rather have a smaller, plain text email than a 80kB CSS monster when I’m on the go :-/

Can the tech industry please stop messing with everything and thereby actually making things worse? :-/!