NaturalReader 9 running on Linux Wine...

  The installation of Mint 17.3 Rosa, (Trusty), 64-bit, on an adjacent partition got me wondering if there were any performance improvements to be had when running Windoze app$ on Linux Wine 64-bit.  I was particularly interested to see how NaturalReader 9 fared.  As I've alluded to in past posts, I bought NR 6.6 way back in 2007 and qualified for upgrades up to NR 9 - or until I didn't - the NR download-link just went dead on me!

 My opinion of NR has always been, at best, luke-warm.  NR is basically a poorly implemented front-end for the AT&T text-to-speech engine.  An apples-to-oranges comparison might be with one of my favourite M$ apps, Wavepad, which similarly, is a front-end for the excellent 'ffmpeg' command-line media tool.  Except that Wavepad is an order of magnitude better programmed!  NR's annoyances I've already commented on in the past, but to its credit, when running on a Windows box, all of the options available on the 'Standard' version (which I bought), do work.

 Which is not the case with Linux Wine.  In fact, NR 6.6 was the only NR I ever managed to get running with Wine, and barely at that.  It would load, and I could play back audio from text in its editor.  Occasionally, it would allow me to save small text-to-audio files as WAV's but never as compressed mp3 or ogg files.  NR 9 on the other hand proved a complete disaster.  I never even managed to get it to install & run, so  was limited to running it on a Windows computer, or from within Virtualbox - both tedious affairs.  So, that's literally 15 years of masochistic involvement with NR & Linux Wine I've endured thus far!

 Fast-forward to today.  While trying to formulate yet another plan to get NR 9 running on Wine, I happened across online, the 'ppa' of a more recent version of Wine, v1.8 versus the ancient v1.62 I've been using for more than a decade.  Up until that 'discovery', I had always assumed that given Mint 17.3's EOL status, newer ppa's had long ago gone off-line - apparently not!  That revelation was followed in short order by yet another find - an even more recent Wine ppa that included 'Trusty' support, this time sporting version 4.0!!!  Within the space of 30min, I had Wine 4 installed and the fun began.

 Or more of the same, take your pick.  On the one hand, NR 9 for the first time, installed & ran.  On the other, the same problem that had blighted NR 6.6, was present with NR 9 as well - it could not detect any 'voices', so no audio play-back was possible!  When initially installed, this horrible software assumes that all of the essentials it requires to operate, were previously installed.  It is only when the program is run, that it realises its mistake, and issues the vague warning about the 'missing voices', but nothing specific that might help correct the issue.

 The dilemma I've faced for more than a decade is, what exactly needs to be installed in order to enable these damn voices?

 This is where I finally made some progress.  'SpeechSDK', a M$ library installable through 'Winetricks', was always conspicuous as a requirement.  And with NR 6.6, once installed, it usually provided the missing voices - though not always - it was temperamental!  But the voices were always missing with NR 9.  After hours of searching, I made the enlightening discovery that 'SpeechSDK' was a '32-bit-only' package - only supporting 32-bit OS's up to WinXP.  Yet, despite this, it would still install on a Wine's 64-bit emulation of a 64-bit Windows OS - it just wouldn't work!  Maddening!!!  The next 'solution' I learnt, was to create a new 32-bit Wine 'Profile', set the OS type as say, Win XP, install SpeechSDK followed by NR 9, and everything would 'just work'.  Except it didn't...

 When it was appearing that installing Mint 17.3 64-bit had been a huge mistake, I eventually hit on a Winetricks-provided solution that worked.

1)    Through 'Wine Configure', set 'Windows version' as 'Windows 2000'.

2)    Create a 32-bit Wine Profile.

3)    Remove 'Mono' if installed (otherwise prevents NET 2.0 install).

4)    Install NET 2.0 (otherwise NR crashes during install).

5)    Install Richedit 3.0 (otherwise manual file-splits painfully slow).

6)    Install SpeechSDK.

7)    Install NR 9.

 Sorted!  'sapi' it turns out was Microsoft's answer to voices for 64-bit machines and is a tiny part of a relatively massive 550MB Service Pack Upgrade for Win7.  On the face of it, this shouldn't work either,  given we're working with a 32-bit Wine Profile, but it does.  All of this of course would have been unnecessary had the crappy NR software checked for missing libraries at installation time and provided what was missing.

 But alas, there's no happy endings where NR is concerned.  I found that with NR 9, I still cannot save converted audio files as mp3, and for the most part, as ogg files either - specifically, with 'normal' settings selected, ogg encoding doesn't work, but with an 'Advanced settings/Customize' option that encodes a stereo ogg-file, encoding works.  This however, is unsatisfactory for 2 reasons; 1) the TTS engine can only produce monaural speech files, and 2) encoding as stereo will double the size of the ogg file that's produced - so my audio-book archives would be twice the size necessary.  What does now seem to work properly is saving as WAV files.  I've just created an entire audio-book this way without a hitch.

 After spending further hours of searching for a solution to the mp3/ogg dilemma, I've come to the conclusion that there isn't one.  NR uses the standard 'lame_enc.dll' for its mp3 encoding.  Apart from it being a relatively ancient single-thread encode version, it works perfectly when run natively on Windows.  It just won't run at all on Wine.  I can only conclude that the idiot(s) that programmed NR, are passing parameters to the encoder dlls in a non-standard way.  'foobar2000', the excellent & free M$ media player employs the same encoders and it works perfectly.  To pour salt in the wound, I recently came across another piece of TTS software - TextAloud.  As luck would have it, this works perfectly - it includes & installs if necessary, the M$ TTS 'voices', so that playback, encoding etc. 'just works', out of the box.  Coming across this 15 years ago (had it existed) would have made my life so much easier.

Edit:

 I should have guessed that the somewhat ebullient tone of this post would prove fleeting & short-lived.  I presumed that the results above, other more up-to-date Linux distros, would also inherit - but this has proven not to be the case.

  Having tried & failed to get Chrome Remote Desktop working properly with ANY of the distros I have installed on various computers, I stumbled across another remote access piece of software from https://www.dwservice.net (DWS) that works fantastically on everything I've been able to try it with, namely Windoze, Linux & Raspberry, but it also works with Mac and a couple of others I can't remember.  Unfortunately, with Linux, it's a newish 64-bit OS only affair, but the performance of DWS convinced me that it was worth the effort of installing Mint 21.1 64-bit on my old laptop workhorse.  I may actually review this here at some stage, but for now, suffice it to say that it performed better than I expected it to, and DWS worked perfectly with it.

  Mint 21.1 'seemed' to work so well, I decided to install all of the 'essentials' I rely on, and this obviously included Natural Reader 9.  So imagine my disgust when after installing Wine 6 from the repositories, NR9 refused to run without crashing.  Indeed, it sometimes refused to even install, and despite trying everything possible, going as far as installing a pre-6 version binary of Wine, I'm back to square-one, with none of the above working with Wine 6.  Sickening.

 The fairly lengthy period of time I've spent trying (again) to crack this problem has only managed to highlight glaring problems with Mint 21.1 itself, the most damning of which are frequent system lock-ups - along the lines of 'kernel-panic' errors - and for no obvious reason.  In one instance, the power-off button itself had no effect, removal of the laptop's battery being the only solution to restart the OS.

 So, all in all, a demoralising experience.  NR9 when coupled with Wine is still the shitiest piece of software I've ever come across, and Mint 21.1 just doesn't make the grade as a permanent replacement for Mint 17.3 - so a double-whammy!

Edit1:

  I've edited the above 'How-to' slightly, casting aside 'sapi', and reverted back to using just 'SpeechSDK'.  Technically, while 'sapi' was a replacement for SpeechSDK, developed in readiness of the switch-over from 32 to 64-bit OS's (Win7 64-bit and up) it also works fine with the 32-bit version of Win7.  Since most M$ apps that I use worked fine running on Wine 4.0, I built a 4.0 binary from the Wine 4.0 source but on Mint 21.1 64-bit, fully expecting the same apps to run perfectly on it.  They didn't!  In fact, all that would run were parts of Wine itself, such as 'winecfg' & 'wine uninstall' - no Windows app would run!  After a bit of reading, I learned that Wine relies almost exclusively on 32-bit libraries in order to run Windows apps.  Given that practically all Linux OS's are now 64-bit in nature, this complicates matters out of all proportion - for a usable Wine setup, you have to somehow build it on a 64-bit system, but using 32-bit libraries!  According to the online How-to's, 'chroot' & 'lxc' are the two most viable options.  I've tried & failed using the 'lxc' method - I managed to create the 'lxc-container' ok, but couldn't for the life of me get it to 'Start'.  But even if I had succeeded in this 'first-step' of creating a build-container environment, I then have to locate all of the essential 32-bit Wine libraries.  The crazy thing is that there is no step-by-step information on how to do all of this online, that I've been able to find anyway.  So right now, I'm done with it.

 What I did manage to do was build from source, Wine 4.0 on my old 32-bit Trusty (pun intended) setup and have uploaded the binary to Google-drive, with the link provided here.  Remarkably, 'ogg' encoding now works perfectly!  This 'success'  prompted me to spend loads of more time trying to get 'mp3' encoding to work as well - unfortunately, all for naught.  Out of boredom, I also tried installing this on Mint 21.1 64-bit - knowing 'full-well' that it wouldn't allow it - but install it did, and without issue!  What it didn't do was run Windows apps or give any indication that Wine had even installed!!!  I felt like I was being toyed with...

 As the saying goes;

     "Those whom the Gods want to destroy, they first make mad". 

 Edit2:

    Yep, NR is proving to be the gift that keeps on giving.  I decided to set up a fresh Mint 17.3 32-bit on another PC, complete with NR.  Following the above list in order to get it going, I found it didn't work!!!  The issue turned out to be that the version of 'winetricks' used is of over-riding importance - I'm including it here for completeness.  Whatever magic this version manifests, it appears to be a necessary ingredient in getting this crap to run with voices enabled!  Although above I include creating a new Wine profile as a necessary step, it isn't really, so can be left out.

Aldi/Lidl LED Bulbs...

 Quick post this.  In the Incandescent Era, the replacing of light bulbs was expected & understood - metal glowing white-hot for months on end, could only be expected to end in a flash, right?  Then along came LED bulbs, whose longevity & efficiency, we were assured would deliver us from perpetual bulb-changing.

 Well, it appears that the Aldi & Lidl supermarkets around here didn't get the memo, cos' they keep flogging crap to me.  I bought & installed a handful of lightbulbs about a year ago, and in the past month, have had three of them fail, all within days of one another.  The cynic in me suggests that it's more likely to be a case of 'planned obsolescence' than the Bulb-god calling his children home.  They're not running hot either, the usual excuse that's trotted out.  So how can a bulb just warm to the touch, not last much longer then an incandescent that you could cook your dinner on?

 But for the fact that I possess an LED bulb that was bought 10-12 years ago, I'd be inclined to take their claimed longevity as a whole, with a pinch of salt.  [Edit: I tell a lie, just recalled and photo-snapped a second ancient but-still-working LED bulb that's in my possession,  and interestingly, both use identical LEDs]. Nevertheless, lots of the claims made by LED bulb manufacturers, rarely seem to be borne out in practice, in my experience anyway.

 Below are pics of the batch of Lidl bulbs that I bought, and that are failing as if to order.  Included as well is a pic[s] of the only [2] Chinese bulb[s], out of about a dozen, all from different manufacturers, that I got 10+ years ago.  The first has been running 6-10 hours, day in & day out, since I bought it.  The other, a low-lumens affair, also produces that horrible white-light, so has seen more limited usage - yet still orders of magnitude more than the 'Livarnolux' crap that Aldi/Lidl sold to me.

Edit1:

 With 3 blown bulbs knocking about & time to kill, I decided that a little investigatory work to determine the nature of the failures might be in order.  Although the symptoms leading up to each bulbs demise weren't identical, I figured that each must have had a common thread.  The first oddity I came across was that although physically identical, one of the bulbs weighed over THREE times that of the others (see pic) - so, being the piggy in the middle, marked it out as the first victim. [Oops, though all are made by Livarnolux, and look identical, this one has a different model number.  It is also rated at 12W, the others are 9.5W].

 

 

 Removing the globe itself was trivial, getting at its entrails proved anything but.  First discovery was that the LED's themselves appeared to be in perfect condition - this was always the weakest link in all of the half-dozen or so LED bulbs I've tried repairing in the past, the burned-out LED normally being easily discernible.

 

 With the LED module removed, the source of the extra weight was apparent - a big hunk of metal, clearly meant as a means of removing excess heat from the LED's.  This also suggests that this 'version_2-kludge' was an attempt to rectify a problem with a prior version - one that obviously failed!  But what they lacked in competence, they made up for in craftiness, attempting to ensure that no one else could fix it either - by encasing the entirety of the electronics in soft plastic!!! (see pic).

 

 

 Needless to say, removing it proved a real chore, first, just getting the PCB from the bulb's plastic housing without breaking stuff, next, having to chip away at the 'sarcophagus' encasing the electronics, and all without damaging components.  But endeavour to persevere I did, and after about 2 hours, had something that I could at least attempt fault-finding on.

 

 It didn't take long to trouble-shoot either, seeing as there's not that many components involved.  It turned out to be that an electrolytic capacitor had failed - 22uF in name only, was now just 4-and-change.  Replacing this with something half-way similar, had it up and running again (see pic).

 

 Of course, there's no putting the genie back in the bottle with this bulb, as I damn near had to destroy it to 'fix' it.  Note above that the measurements were made with only 60VAC applied.  This was partly because that was blinding enough, and partly because the electrolytic I replaced was rated at 50v versus the 63v of the blown one.  And also, when I wound it up to 100VAC for more than 10 seconds, something started to smoke - always a bad sign!  [Hmmm, further tinkering revealed that the 'smoke' was a result of the circuit hitting a 'dis-resonance' of sorts at specific voltages.  Increasing the AC voltage gradually via the auto-transformer as I did, above 60v, the current would increase rapidly, causing a current-limiting resistor to whimper.  However, jack the voltage right up above the 'un-sweet spot', or even straight to 240v mains potential, and everything ends up smelling of roses, the circuit being perfectly behaved (see pic).  Measured efficiency is only 75% for this 12w bulb - that's a whole 3 watts going abegging.  I'd have expected better from a deliberately expendable design such as this]. 

 

 With the failure of an electrolytic in a LED bulb, it gets you thinking.  By their very makeup, electrolytic capacitors WILL fail in time, it's guaranteed.  Google throws up numbers, that between 1,000 & 10,000 hours use, you should expect failure.  There is no way any of my blown bulbs had 10,000 hours of use.  I doubt the longest-lived had more than 5,000 hours, and I'm sure that one had less than 1,000 hours of light use.  And when they fail, it's not the LEDs that die, it's a shitty component that the text books will cheerfully tell you, is bound to fail!  Were they to use tantalum capacitors, Google talks about them lasting 20+ years.  Which will never happen, not in the 'throw-away society' we live in.  It just grinds my gears that a consumer item with fractional energy bills, is deliberately designed to last no longer than the incandescents it replaced. 

Edit2:

 Having some time to kill, I decided to investigate another of my dead Aldi/Lidl bulbs.

 Though the failed bulbs may look identical, this one shows that they are anything but.  This design screams 'CHEEAAAPPPP', a bean-counter's wet-dream - there's almost nothing in it!!!

  On the one hand, there's elegance in its simplicity.  The PCB is comprised of a current-limiting resistor, a bridge-rectifier and a reservoir capacitor, that's it!  This high voltage DC (300V approx) is applied directly to the equally-simple LED panel, made up of LEDs, a current regulating I.C, and a handful of resistors.  All of the LEDs are paired, connected in parallel, then each successive pair connected in series.  Given that 300VDC is powering this string of LEDs, they are atypical LEDs, having large voltage drops, which curiously, are not the same - the first LED-pair's voltage-drop is around 15v, the next pair in the string is around 30v, which continues similarly to the end of the string.

 This is also the Achilles heel of the bulb - one faulty LED-pair and you're in the dark!  Although none of the LEDs are visibly damaged, when I apply the turn-on voltage to some of the pairs, their brightness changes erratically.  I guess designing LEDs with such high voltage-drops is still in the development stage!

 On the other hand, there's nothing fixable with a design such as this.  The other bulb pictured above is a delight in comparison.  Hell, this bulb has only half the LEDs, but the same Lumens-rating.  True, it has a marginally lower power-rating (9.5W versus 12W) but the LEDs must still run much hotter, especially when you consider how flimsy the aluminum heat-sink used is - one-third the weight, remember!!!

 I'm not surprised that a version_2 was called for. 

Kosan Clip-on Butane Regulators...

 It's that time of year, when the central heating alone just doesn't cut it.  So off I go, buy a new canister of gas, wheel out the much-despised Kingavon, only to discover that another Kosan gas regulator has decided to quit on me!

 Yep, that's three now, and at this rate, I'll be averaging one per canister.  And I'm not even joking, this is only the second gas refill with the last regulator Calor sent me (gratis) - so it literally lasted just one canister!!!

 In the hope of getting some traction with Calor, I recorded a short video, which is linked to above, of what I'm seeing with a full gas canister fitted.  Not so much with getting another free regulator from them - I think they're lumbered with honouring the 5-year warranty on the last one they forced me into buying - but getting someone there to at least consider changing regulator suppliers.  These Kosangas regulators are garbage.

 So bad in fact, that I finally decided to bite the bullet and try and figure out what's causing all these failures.  Given the dearth of findable information available online about any of this, but faulty regulators aplenty, the only viable option was to try opening one up and having a looksie.

 These regulators are definitely designed as 'non-serviceable' items, but with a little finesse, along with a junior hacksaw, I soon got to look at its innards.  There really isn't much in them, basically a spring-loaded diaphragm that controls a gas inlet valve.  Unfortunately, its 'non-serviceable' nature also extends to the guts of the device, and I was unable to gain access to the inlet valve itself, as the white nylon control arm's pivot pin is of the interference-fit-mounted variety.  Though it's probably not obvious in the photos, the whole of the inside is covered in an oily residue, which I initially figured was gas-derived, but now I'm not so sure.  Maybe it's there by design, a gas-seal for the diaphragm for example.  The one thing that did stand out though, concerns what I've labelled the white nylon control arm.  It is controlled by the diaphragm, which is itself controlled by the gas pressure.  I found the control arm relatively easy to jam in the closed position, which prevents any gas from entering.  This is exacerbated by the unnecessary close tolerances employed in its construction, with barely 0.2mm clearance between it and the central metal nubbin that it swings about.  Thankfully, being nylon, so almost impossible to break easily, it was relatively easy to stress each of its arms enough, that it touching the sides during its travel, was no longer an issue.

 So, is this a 'fix'?  I don't think so.  Of the three regulators, the oldest two were completely useless, and allowed no gas at all through.  The 'new' one is already almost unusable, so appears to be following the same path of getting permanently choked off.  I'm left concluding that either the gas inlet design is inherently flawed, or the oily residue that builds up, eventually blocks the inlet, or at least locks the control arm in the valve-closed position.

 But while it may not be a 'fix', and definitely not a permanent solution, right now, the broken regulator is working again!  It's back together, everything held in place with electrical insulation tape, and 2-3 bars burning bright.  But in the few hours it's been running, it appears that it may be showing signs that the gas may be slowly getting choked off.  Time will tell...

If nothing else, it's been interesting.  Next step, contact Calor about a new & safer solution.  Unfortunately, I'm pretty sure it's going to be another of these Kosan travesties.  To head off that eventuality, I've recently discovered an old-type clip-on regulator that will be interesting to test.  As of now, I'm of the opinion that Calor has 1000's of these faulty (in-time) regulators and is knowingly flogging them to its customers.

 

Edit:

 I've been playing with the old Kosangas regulator I mentioned above for a day or two, and things are looking good.

...well, maybe not the regulator itself, which clearly has seen better days, but the prospect of a resolution may be in the offing!  Yeah, despite its age, it's still working perfectly.  Bear in mind, while the brand-spanking new-design Kosan regulators also worked perfectly in the beginning - all 3 of them - they all effectively died after just a couple of gas-refills.  Whereas, this old Kosan(gas) design is still going strong, no doubt, having had already regulated a lot of gas in its day.

 I videoed the old regulator in operation here.  However the flame-colours look completely washed out in 'normal' artificial light, don't know why.  Suffice it to say, the old regulator performed admirably.

Alkaline Vs NiMH Battery Comparison...

  One of my first blog posts here, nearly 10 years ago now, questioned the veracity of Alkaline battery manufacturer's claims.  I suggested at the time that us rustics were being fed a line of baloney regarding both Alkaline battery capacities & their oft-touted performance under heavy loads.  I also hinted back then that I'd test the claims, 'when time allowed'.  Well, here it is, Testing...

  First a note about my setup.  Above are the 3 electronic-loads that I have at my disposal. The 'green' one, my first purchase, is capable of providing 60W of loading, whereas the other 2 'black' ZKE loads manage only 30W.  This disadvantage is offset by the fact that the green load's minimum voltage/current settings are 1V/200mA, whereas the ZKE loads are 0.1V/50mA - therefore much more useful for lower voltage/current testing.  Unfortunately to their detriment,  the ZKE load's firmware sucks!  While the green load, during test, will cycle the display continuously, at 1 second intervals, between instantaneous, voltage, Amp-hours and Watt-hours, the ZKE loads must be switched manually to see what's going on - a real handicap when batteries are electrically connected via neo-magnets as you see here, as one's curiosity, followed by the slightest nudge to the test apparatus, can result in an intermittent disconnection, and a ruined test.  Maddening, when you're say, 30+ hours into a battery test - as happened with me here, as well as many times in the past!  Another huge plus for the green load is that when a test completes successfully, the results will be saved to non-volatile memory, which will then survive even complete power failure, and will be restored on power-up and can be stepped through manually by the user.

  Hardware-wise, the ZKE loads are also sub-standard.  While both load-types are fan-cooled, only the green tester uses variable fan-speed cooling, dependent on the applied load - unbelievably, the ZKE load's fan will ramp up to full speed and remain there, irrespective of the load being provided, for the entirety of the test.  In fact, when I got the first ZKE load, I presumed it was faulty because of this.  What was much more worrying however, was that even during a 30W test, the fan speed would vary erratically, going from full speed to on occasion, stopping entirely!  Thinking that this was down to a firmware bug, I sent a video (link here) of this behaviour to the Seller (and manufacturer) of the electronic load, and got another one sent to me, gratis - the only reason I have 2 of them!  I was not impressed on powering up the replacement to discover that the 'full-speed always' thing was the rule, not the exception!  The final insult was delivered not more than 200 hours later (test-wise), when the fan on the replacement load also failed!  Evidentially, the manufacturer opted for the cheapest fans possible, which employ dirt-cheap 'sleeve bearings', and from what I've read, are a complete no-no for fans that need to be mounted horizontally.   What's particularly perplexing is that as I type this, the exact same ZKE load is for sale on Aliexpress for between $40-$50 - that's literally twice what I paid for my one, 4-5 years ago.  Whereas the identical green load is also available on Aliexpress right now, but for between $18-$20 - exactly what I paid for it 5-6 years ago!  Makes no sense.  But (as always) I digress...

Batteries in play.

Alkaline Aldi Activ Energy (AA, AAA) - all well-within their expiry dates.

Nickel Metal Hydride battery: Panasonic Eneloop Pro (AA)

Generic 'Tronic' NIMH Aldi Rechargable (AAA)

  First off, I did an apples-to-apples comparison between the loads in order to convince myself that the (suspect) ZKE load's test-results were accurate (see pic).  I checked both load-types using the same Aldi Tronic AAA NiMH battery, and employing the same voltage cut-off/current settings.  In practice, I did a lot more than this, comparing both Eneloop & Eneloop Pro AA batteries, but the AA/AAA results will suffice here.  The Cut-off voltage used was the 'non-standard' (for NiMH) 1.0V and Load-currents of both 200mA & 500mA gave results that didn't vary appreciably between electronic loads.  These tests were enough for me to warrant proceeding, sacrificing a few Alkalines in the interest of curiosity, if not science.

  Given the relatively huge 200mA 'lowest' current that can be set with the green load, coupled with its 'above-standard' test-complete voltage of 1V, I decided to confine all my testing to the ZKE load.

 

  My first test of an Alkaline AA @ 200mA with a cut-off voltage of 0.9v resulted in a tested capacity of just over 2000mAh, which I found disappointing, and reckoned the poor result was down to what I considered the large (for Alkalines) current draw.  This test also highlighted a[nother?] firmware bug in the ZKE - notice above how the mAh and mWh readings for the Alkaline AA test are identical, though try as I might, I have been unable to reproduce the problem!  Anyway, to test my Current hypothesis, a second alkaline AA was tested, this time at a much higher 500mA current draw.  Confirmation however wasn't forthcoming, as the battery performed surprisingly well, indicative perhaps that alkalines aren't as awful under load as I had presumed.  Unsurprisingly, it delivered marginally less than battery 1's 2000mAh.  I then decided to test a third at the minimum-allowable 50mA current-draw, a decision that proved to be bone-headed, as this quadrupled the test-time to about 40 hours.  Three-quarters of the way through, I 'nudged' my test setup while checking the current values, resulting in one prematurely terminated test.  Grrrr, infuriating.

Finally, some Aldi/Lidl AAA battery testing.

 As can be seen below, the old, well-used NiMH battery outperformed the new, unused Alkaline by an appreciable margin, itself a surprise, given my past experience with 'Tronic' batteries - basically, they've never provided their claimed capacities, even when new (1000mAh in this instance), generally deteriorating rapidly over time, before failing entirely.

 So, what have I learned from this?  First off, the capacities of 'one-shot' alkaline batteries do not seem to appreciably exceed that of 'quality' NiMH batteries.  In fact, they may not even approach Premier NiMH battery capacities - my Eneloop Pro batteries, ordered through Aliexpress, to me, have always seemed 'suspect' - they have NEVER been seen to provide their stated Minimum capacities, namely 2500mAh, all 4 instead managing just marginally over 2000mAh.  Whereas my Standard Eneloop batteries, ordered through Amazon, performed to specification from the get-go, delivering (when new) the advertised minimum capacity of 1900mAh.  But I've whined on about this in an earlier post, so 'nuff said!

 Before this, I figured alkaline's 'edge' must be in their higher 'nominal' voltage - 1.5v versus NiMH's 1.2v.  Surely, I thought, this 20% higher voltage would deliver 20% higher capacities, when measured in mWh.  Not the case as far as I can see from the testing that I've done.  In fact, this higher-voltage 'advantage' would seem to me an artificial one, imposed on us by the battery & electronics manufacturers.  A good example of electronic goods that almost demand alkalines are cheap LED torches.  With LED's fixed voltage-drop, NiMH batteries manage to provide only a fraction of 'useful light' time that their alkaline compatriots provide - despite still retaining much of their initial charge 'when the lights go out!".

 Summing up.  I'm more convinced than ever that alkaline batteries are a rip-off, and in no way represent value for money.  This is particularly evident when it comes to powering heavy loads - something that manufacturers often cite as being their forte, particularly around Christmas time.  Even were we to agree that one alkaline costs perhaps a fifth that of its NiMH compatriot, itself unlikely, their 'one-shot' nature would still see NiMH outlast them by at least 100 times.  In fact, the only true advantage alkalines appear to have over NiMH batteries is 'shelf-life', ie. the ability to retain charge, unused, over extended periods of time.  But even this advantage has seen continuous erosion as 'quality' batteries like Panasonic's Eneloop continue to improve - I think the newest generation retain more than 90% of their charge after a year.  Add to that, appliances like smoke-detectors, where alkalines were always the de-facto choice, must be seeing a decline in their use.  For example, I've got a few powered by both alkaline and NiMH 9v batteries, Soshines in the latter case.  The NiMH batteries seem to last just as long as the alkalines - so why continue to waste money in what to me seems to be a defunct technology?  One thing's certain, if we continue to buy them, the manufacturers will continue to churn them out.

Anker Soundcore Life Q30 Headphones...

  I bought these 'over-ear' headphones 9-10 months ago on Aliexpress, and they weren't cheap, costing $86 back then - right now they're selling for $98.  Up until a few days ago, I was an Anker fan-boy.  They performed admirably, being comfortable to wear, had a long battery life, great sound and effective noise cancelling.  Basically, as advertised - what wasn't there to like! - and my positive review on Aliexpress reflected this.

  However, a few days ago, I discovered a design flaw that has left me feeling rather peevish.  Two plastic 'clips', used to help couple the headband to the earpieces, have cracked, with chunks after falling off & now lost (see pics).  Having treated these headphones with 'kid-gloves' ever since I got them, I'm certain that it's not down to physical abuse.  The fact that the clips on both sides have cracks & pieces missing, is all the proof I need to show that it's a design issue.  Being a  mere 6mm, they can be seen to visibly flex whenever the earpieces are separated when being placed on head.  They are in no way strong enough to endure this for long -  I guarantee that anyone buying these, will experience the same problem in short order.

  I tried updating my Aliexpress review, only to discover that it's no longer there!  I've raised this point already in another post, the fact that Aliexpress Sellers (apparently) can just pull & resubmit their advert, wiping all customer reviews in the process.  Not only does this render the review process from the Buyer's perspective, pointless, it also forms a 'rinse & repeat' haven for Sellers of shoddy goods - place ad & sell until such time as negative reviews effect your profits, then pull ad, resubmit and repeat!  Shouldn't be allowed.  In contrast, Amazon purchases, a decade old, can still be edited by the Buyer.

  The only upside here is that I noticed the problem before either of the clips snapped off completely, so had the opportunity to apply a fix - basically, just a couple of miniature black cable-ties, tightened and secured with B7000 adhesive (see pic).  Not too hideous in appearance, with the added advantage that they 'point the way' when matching ear-to-earpiece.

  Incidentally, the B7000 is another recent Aliexpress purchase, that is not living up to the advertising.  It's not awful - turns out it's basically just a watery Evostick/Bostick-type glue, with a rather clever applicator, so easy to apply accurately.

  By the way, the Q30's claimed 60hrs(ANC Off) / 40hrs(ANC On) usage between charges is horseshit.  True, it lasts quite a bit, but you'd never see 60 hours.  It turns out that the ANC, while effective, is not spectacular, so a bit of a gimmick as far as I'm concerned.  As a result, I almost never have ANC (Active Noise Cancelling) switched on.  Same for  'Transparent' mode, which gives a bit of a boost to the external audio, so would impact the run-time as well.  Seeing as I'm posting this, I'll probably do a run-time test on the headphones and post my results here before long.  An easy claim to test would be Anker's 4hrs from a 5min charge.  Stay tuned.

Update.

 Looks like I'll be eating crow again.  Runtime tests complete and I must admit, I'm gob-smacked.  As a preliminary, while listening to music, audio-books, etc. I ran the Anker headphones until they powered off, then waited 24hrs, and did the same again - just to make sure that its battery had no significant charge remaining.

 First test was the easy one - Determine the listening time possible from a 5min charge.  Seeing as the Ankers don't come with a charger, the one I used had dual 2.1A USB outputs, which is a far greater charging current than the Ankers require (measured Max Current was 0.61A).   Being finicky, I regulated the charge-time precisely, using an electronic switch to switch the charger on/off - resulting in a charging period that was accurate to 1sec.

5min charge: ran for 3hrs 57 minutes.

 Wow, just 3min off the claimed 4hr listening time - I was impressed!  But it got even better;

Listening timed-sessions from fully-charged.

Session 1; 5hrs.
Session 2; 5hrs.
Session 3; 3hrs 10min.
Session 4; 5hrs 30min.
Session 5; 8hrs.
Session 6; 9hrs.
Session 7; 6hrs.
Session 8; 2hrs.
Session 9; 6hrs.
Session 10; 6hrs.
Session 11; 4hrs.
Session 12; 3hrs 30min.
Session 13; 5hrs.
Session 14; 5hrs.
Session 15; 4hrs.

Total time: 77hrs 10min.

 That I certainly did not expect, that's one extraordinary amount of listening-time between charges!!!

 Edit. 

 A quick update to highlight a MAJOR problem with the Anker headphones.  As can be seen from the photos below, the padding on both ear-pieces have split along the join-seams, exposing the foam inside.  These are critical, non-replaceable items.  Although I only have pics of the latest padding failure, its companion had split in a similar manner, but thanks to 'Super Glue', I caught it early, and it is at least usable again.  This time round, the split was more extensive, and after the photo-shoot below, was compounded when I tried repairing the damage - it split a full 180 degrees!  As a result, the final 'repair' is a bit of a mess, lots of glue evident, so it will probably be uncomfortable to wear.

 As it happens, identical 'splitting' occurred with the MPow headphones, though being smaller, proved infinitely easier to glue.

 So riddle me this, what good are headphones that are comfortable to wear, with superb battery life, have excellent sound & user options - but have cheap, irreplaceable ear-pads that WILL fail in a relatively short amount of time?

 Yep, not feeling so good about this purchase now.  Thank God for Super Glue though.  Without it, repairing this type of damage would be nigh impossible.

An Post (Ireland's Postal Service) - is the pits...

 More venting I'm afraid, this time, it's regarding our much maligned postal carrier, An Post - 'The Post' in Gaelic, to the uninitiated!

 First, the backdrop.   Way back in January 2021, I ordered an Atari ST USB transfer interface from a guy in the Czech Republic, namely, the PARCP-USB adapter.  A couple of months passed, no package, but as the 'sc@mdemic' was in full swing, I figured this was the reason, so patiently waited some more.  Alas, in vain.

 No biggie, I figured, the package had a Tracking number after all.  And tracked it was, at least on the Czech side, the carrier having acknowledged receipt & dispatch of my order to the Emerald Isle.  But no further - it never found its way onto An Post's tracking system.

 I contacted the Seller, who promptly got onto the Czech postal carrier, and relayed back to me that said carrier would contact An Post, who in turn would contact me.  More months passed, but eventually I did get a letter via snail-mail from An Post requesting a signed & returned form to them, acknowledging the non-receipt of the Czech package.  This I did.

 Fast forward another 9 months to today, a full 15 months since the order had been placed.  With no further follow-up from An Post, I attempted to submit a Lost Package request via their web-site, only to discover that either their system hasn't been updated since the 80's, or that they are deliberately trying to limit the number of successful Lost Package submissions to a minimum.  The problem? - An Post doesn't appear to realise that most online ordering these days doesn't require the buyer to submit, or even have knowledge of the Sellers address & telephone number - BUT INSISTS THAT THESE BE PROVIDED IN ORDER TO PROCEED!!!  This is insanity.  Had I ordered from Ebay, Aliexpress or Amazon, would I be expected to source name & address details for any of these behemoths?!?!?  Or in my case, from a small commercial Seller.

 So, Unable to proceed any further on that front, as a last resort I turned to An Post's online-help - and what a farce that turned out to be.  After trying to explain all of the above 'live', and in as concise a manner as 'live-help' will allow, I was told flatly that there was no trace of my order "on their system", and that the Seller probably hadn't even sent it! Exasperated, despite having told (typed) to bubble-head "Paulina" that it was the Czech Carrier that had contacted An Post (not me) about the missing package, and that An Post had then sent me the letter, requiring acknowledgement of non-receipt of package!!! - indication enough I thought, that the Seller had indeed posted my order, and that the Czech carrier had indeed passed it onto An Post - but all of this was lost on poor "Paulina".  If it wasn't on "their system" I was told again, then it 'obviously' hadn't been sent in the first place!  I started to type that if it was on their system, it wouldn't have been lost and I wouldn't be here trying to explain the obvious to her - when in mid-sentence, I'd had enough, and typed "...never mind, fuck off!" and disconnected!  But not before their automated 'cuss-word detection spat back that "abuse" would not be tolerated and that the infringement had "been noted".  This at least gave me a laugh.

 An Post is clearly an institution more worried about its bottom-line, than about helping its customers.  Any company whose sole response is to deny all responsibility for a missing package, by citing "well, it's not on our system, so we can't have received it.", despite the loss having been initially brought to their attention by a fellow postal-carrier, deserves to fail.  I've ended up losing €50, but I can easily envisage An Post losing quite a bit more, and deservedly so.  I just hope it won't be at the tax-payers expense.

Edit.

 I forgot to include what triggered my potty-mouth, the straw that turned exasperation into infuriation.  'Paulina' had the gal to insist, more than once, that it was the Seller, not the Buyer (me!) that should be requesting this information from her, and that I should instead be communicating with him - which I took as short-hand for, "Just go away & stop bothering me!"  But if this is 'company policy', and not just bubble-head having a blonde-moment, then it is indeed sad.

 Final Edit.

 I took one last stab at this and filed a complaint with An Post.

To whom it may concern.

An Post lost a package (value €50) containing an item at I ordered from the Czech Republic, order placed on 23/01/2021.  This was while the COVID hysteria was in full swing, and I presumed the parcel had merely been delayed - but after 6 months, it still hadn't arrived. (Seller's name: Petr Stehlík <pstehlik@sophics.cz>)

I know An Post lost it because the Seller, on hearing that I still had not received the item, contacted the Czech Postal Service, who informed him that they had handed it off to An Post - the package's online-tracking, available to me at the time,  seemed to confirm as much.

The Czech Postal Service also told the Seller that they would contact An Post, who would in turn, contact me about this.

This An Post eventually did (after about 6 months) in the form of a letter asking me to return a 'parcel-not-received'  form to them, confirming that I had not received the package in question.  This I promptly did.

Then nothing.  An Post never followed up on this.

As a last resort, I recently tried to resolve this issue via An Post's online-chat service, which proved to be a fiasco.  I tried explaining all of the above to the person I communicated with, but they had either a limited attention-span, or more likely, were merely working from a prepared script designed to fob people off.  Nothing was achieved but the raising of my blood pressure. 

Question.
How can An Post, simply shirk off any responsibility for a package that gets lost, when online-tracking at the time confirmed what the Czech Postal Service had asserted - namely, that they had successfully handed it over to An Post?  Remember, it was An Post that contacted me about this initially, not my contacting them, and after they had been contacted by the Czech Postal Service.  This in itself is a clear indication that the parcel went missing after it had been handed over to An Post.  The online-help(!) person I spoke to had the gal to state, several times, that if it wasn't 'on the system', then it COULDN'T have been received - so, An Post's omnipotent now...  She went on to state that neither was there a record of the form of non-receipt that I had returned to An Post, "on the system".  If that truly is the case, then that's two letters, not just the Czech parcel, that An Post has managed to 'lose', at least in the shirking responsibility sense.

There is no doubt in my mind that the parcel was lost by An Post.  The fact that An Post contacted me, seeking confirmation that I had not received it, is evidence of such.  But what was the point in having me return a non-receipt form, if policy is just to ignore it?

Respectfully,

xxxx

 Unlike their follow-up on my missing parcel, their almost instant response was succinct and to the point.

Good evening xxxx, 

 

Any package or item that goes missing or is failed to deliver has to be investigated by the sender of the item through the original postal service. 

 

The letter sent to you to confirm non receipt is done to be sent back to the original postal service in the Czech Republic. We would have no further dealing with yourself and would only engage with the postal service in the Czech Republic who would engage with the sender of the item. It is then the sender of the items job to engage with you for any further dealings. 

 

We cannot do anything further for you. 
 

Kind Regards

 

Aaron

Customer Services

 At least I appreciate that they responded quickly, giving me a straight answer, unlike that useless drone I communicated with via live-chat.  In a nutshell, on-line Tracking is a mere courtesy, and even if, (as here), it strongly suggests that it was An Post that lost my package, it has no value in proving culpability - basically if An Post loses a non-insured package, it's a case of...

 'TOUGH LUCK CHUMP!!!'

Wavepad And its Shortcomings...

 With a mammoth fortnight of experience using Wavepad under my belt, I thought I'd share my musings on a few things about it that rub me the wrong way, though I should preface any criticisms by saying that Wavepad is by far, the best audio-editing software I've come across to date, making one of the most tedious parts of producing small or large audio-books, now a doddle.

 As mentioned in my previous post, on my setup, (little RAM, no SSD space available), with large WAV files, Wavepad is slow.  As also mentioned, this is compounded by the fact that it has to use a hard-disk as its cache, but given that this drive is relatively fast (90-100MB/s), it seems slower than it should be.  This sluggish performance is exacerbated when you try adding other available editing options to the mix.

 For instance, Wavepad allows files to be split at 'silences' that it detects in the audio file.  I was almost salivating when I first realised that this feature existed, only to end up despondent when I saw just how slow it rendered the Split process.  Worse, this, ’splitting at silences' doesn't appear to be done intelligently.  While I appreciate that scanning for silences may be inherently slow, the split-files that Wavepad ends up producing, vary widely in length - by as much as 20 min for the 6 hour audio-book (split into 3 pieces) that I created as a test.  Given that there is an option for the user to specify the duration of silences that are sought out, as well as the split-number, what ought to happen is that Wavepad should first calculate the split-points, then search forward & backward from these points, until it finds the nearest appropriate silence.  What it actually appears to do is to scan the entire file for silences, which is idiotic, particularly given that 'synthetic voices' like that produced by the AT&T speech engine, which Natural Reader (NR) uses, introduce silences of precise duration into their WAV files, which should make end-of-sentence silences, quick & easy to detect.  Wavepad's shoddy 'split-on-silences' implementation renders the whole notion impractical, given the "rough", (Wavepad's description), split-file lengths that it produces.  At a minimum, Wavepad should place 'moveable' split-points, thereby allowing the user to shift them manually to nearby silences, prior to splitting.  Alas, this 'obvious' functionality is only noteworthy by its absence.

 Moving on, its next bug-bear involves multi-threading, or in Wavepad’s case, lack thereof.  This is one area where, on a multi-core PC, Wavepad should really shine, specifically, simultaneously encoding the core-based number of split-files into their mp3/ogg etc. equivalents.  What it actually does is encode, one part at a time, which is ridiculous.

 Last on the chopping block is its Audio-tags implementation.  After producing a few audio-books with Wavepad, I noticed that when some of them were opened with the VLC media-player, instead of displaying the file by its (renamed) filename, it uses the WAV-file name that NR generated, basically a string of numbers.  These I discovered were being saved by NR as audio-tags, and Wavepad was happily writing these non-descripts to the split-files, which VLC then (bizarrely) used as labels during playback, rather than the actual filenames.  Thankfully, Wavepad allows Audio-tags to be cleared, so after saving/reloading the WAV-file, things work as they should.  But it's just one more unnecessary step that needs doing.

 Nevertheless, Wavepad is an excellent piece of software.  Another huge plus for me is that it runs almost flawlessly on Linux Wine as well.

 As an aside, I've just come across another Windoze app that has left me rather impressed - Atlantis Word Processor.  This tiny 5Meg word-processor is fast & feature-rich while also seeming to run flawlessly on Wine.  I had been using the snazzy-looking Chinese WPS as my word-processor of choice on Linux for years, but only realised a few days ago that accented letters such as 'é', are unceremoniously deleted from the text-body when the file is loaded... - WTF?!?!?  Bewildered by this butchery, I promptly removed it and installed Libre Office 5 instead - only to discover that this had so many (unrelated) problems, that I'd do better to look elsewhere - and that's where Atlantis W.P. came in!  Were I to nit-pick, the only thing missing from it is the ability to import ePub texts - particularly since Atlantis already allows exportation in this format.  In truth Atlantis W.P. supports relatively few W.P. standards, DOC, DOCX & RTF, being the main ones, but the latter is the only one I'm interested in, the result of my e-book to audio-book conversion preoccupation.