I just bought a Zoom H2 Essential handy recorder that I absolutely don’t need.

Patrick Perdue

Another interesting observation about the Zoom H2E:

With an external signal connected to the 3.5mm input, it goes into input overload at +16.1dB. The Zoom H1E clips out at +24.1.
What? 8dB less headroom?
Well, not necessarily so.
I need to do some more testing, but it seems like the input on the H2E is a tad less sensitive, perhaps to better accommodate line level signals, so it could just be making up the difference digitally. The result could possibly mean that it is equivalent to the H1E on the DAC's input, as far as headroom is concerned, or maybe slightly better, despite not looking as good in the digital domain.

The built-in mics, meanwhile, clip at +22.1dB. This is interesting, because with the H1E, both the internal and external inputs reach input overload at the same +24.1dB threshold.

Meanwhile, the Zoom H6E hits input overload on it's X/Y microphone capsule at +19.1dB, but those microphones are intentionally much less sensitive than those of the H1E.
In this case, a higher maximum doesn't always mean more headroom. It's all relative.

Patrick Perdue

Is it just me, or is there no iOS app to control the Zoom H2 Essential as there is for the H6 and H4 Essential?
The custom windscreen and accessory pack are both currently sold out. Because of the way the controls are placed, you need to either use their windscreen, or cut holes in the top and front of an existing one so as to not cover controls.
I'm going to a thing next weekend, so I thought I would just install my Zoom BTA-1 Bluetooth Adapter, put on a more generic windscreen, then control the recorder from my phone. Kind of hard to do that when there is no app for it, though.
It will happily do timecode sync between itself and other Zoom BTA-1 equipped recorders, but that's not what I'm looking for.

Patrick Perdue

There is now an iOS app for controlling the Zoom H2 Essential with the BTA-1 bluetooth adapter. Seems this didn't exist in the very recent past.
I haven't yet played with it, but I imagine it's very much like the H6 Essential Control app.
You can apparently pair up to ten H2 Essentials to one app to synchronize them with timecode if you need to do that sort of thing.
I only have one BTA-1, or I'd try syncing my H2E and H6E's timecode.
https://apps.apple.com/gb/app/zoom-handy-control-sync/id6514314269

Patrick Perdue

I finally got around to playing with the Zoom Handy control/sync app. It's as basic as it gets, and does what it says on the tin.
If you insert the BTA-1 adapter into the H2 Essential, you just open the app, add a device (there is no menu to enable Bluetooth on the recorder or anything like that) and it just works.

With only one device connected (that's all I could test, since I only have one compatible device), There are only three controls -- set date/time, stop and record, as well as a status indicator that tells you what the recorder is currently doing, if anything, how much time is left on the SD card, and the battery level. There are no controls to change anything about the device, such as file format, what microphones are used, mixer settings, ,etc, so it's not as comprehensive as the app for the H6 Essential. But weirdly, the H6 Essential app doesn't have a sync date/time button, and this one does. Makes sense if you are syncing multiple devices at once for multi-channel recording.
So, if you've only got one compatible unit, it's best feature is possibly just using it as a remote start/stop button. The ability to set date/time to your phone's clock is nice though, since the unit tends to forget those pretty quickly with no batteries inserted, and setting it manually won't always be exactly right anyway.

Patrick Perdue

I just noticed that, with the BTA-1 adapter in the H2 Essential, it takes about 6 seconds longer to boot up. I've had the BTA-1 inside my H6 Essential since I got it, so now I'll have to see if it boots any quicker without it.

Patrick Perdue

Here is an annoying accessibility trend that I keep seeing lately.

The way that the Zoom Handy Control/Sync app exposes time recorded to Voiceover is by spelling everything out, I.E. ten minutes, twenty-seven seconds instead of 00:10:27, or 1 hour, fifty-five minutes, thirty-eight seconds instead of 01:55:38.

Since I am using Braille with my phone about 90% of the time these days, I thought it would be cool that I can now silently check the recording progress of my device, which is located somewhere not on my person, by using a Braille display connected to my phone.
Unfortunately, it's annoying, because, with everything spelled out like that, it takes up a ton of cells on the display for no good reason.

The Apple Watch does a variation on this when reporting seconds, by the way. So, it reads like 11:23 and 59 seconds instead of 11:23:59.

Why do people do this? Just give us numbers, and leave the interpretation up to whoever is reading it!

Of course, the Handy Control/sync app actually displays numeric format on the screen for the record counter, only Voiceover gets the expanded version. I verified this by taking a screenshot, then running OCR on it.

Time to send a note to Zoom about this one, I think. It isn't a show-stopper for most people, but it is also not necessary, and actively annoying in some cases. I have no idea if this affects language localization.

Simon Jaeger

@BorrisInABox I've been noticing this too, and even before I saw it in Braille I realized it would be horrible on Braille displays. I wish people would stop overthinking TTS and remember that Braille users exist. I don't understand this trend at all. I also have punctuation customized to report hyphens, so it's extremely obvious now. Definitely send a note to them. You could always ask if there's a reason they decided to do that.

James Scholes

@simon @BorrisInABox While I likewise wish people would stop overthinking TTS, the needs of speech and braille users are not equal, and hence there is a legitimate technical problem if the output of one is just being set up to mirror the other. There is always too much focus on speech in developer APIs, e.g. aria-label was present in the spec and widely supported long before aria-braillelabel.

to put it another way : if it's determined to be legitimately helpful for speech users to get a longer string, it should be technically possible and easy for developers to give braille users a shorter equivalent.

Simon Jaeger

@jscholes @BorrisInABox I see your point in theory, but I'm curious if you can think of examples of when a longer/different speech label might be useful. Most of the time it seems like the standard label could just be modified for conciseness.

Pitermach

@simon @jscholes @BorrisInABox Using the example of time, suppose an app is displaying relative time like 10 minutes ago, and visually shortening it to just M. It's up in the air whether TTS will say the M as "minutes" or "meters", I've seen it being interpreted wrong both ways. It's nice for Braille to have that shorter version while speech is also clear what is being meant. And I think there are definitely times when optimising labels for speech drags braille down where having separate labels would help. IE, in an email client you might want speech to say "unread, has attachments, important" etc where the braille versions could be shortened to something like unr, att, imp, leaving more space for the subject and other info with less scrolling. It's been a while since I used it seriously but iirc JAWS already does this in the email clients FS scripted

James Scholes

@pitermach Exactly this. I'd usually prefer the visible info to be understandable by as many audiences as possible, and for user experiences to match.

But at the same time, a lot of info is visually displayed with icons these days, and I despise unnecessary cognition. If your event details page says "November 5th, from 11 AM to 6 PM", I will be grateful that you've saved me the effort of working out what "five slash eleven eleven amm dash six pm" means. @simon @BorrisInABox

James Scholes

@pitermach Likewise, with the email example:

A lot of fundamental accessibility materials would tell you to give icons informative alt text if they mean something. But who wants to hear "graphic unread", down arrow, "graphic has attachment", down arrow, "graphic possible spam", down arrow, "graphic sender is not in your contact list", "down arrow, "link Earn $5,000 per week by doing nothing!"?

Much better to mark the icons as decorative, make the email element itself focusable, and give it a sensible name. Even more user-friendly if you then let me control which fields are included and in what order. @simon @BorrisInABox

Rebecca

@jscholes @pitermach @simon @BorrisInABox Sadly sighted testers don't think of braille when they should. Better yet have someone who uses braille test it. I recently learned that sighted testers use and think about screen readers differently than we do. They might see an issue that really isn't one.

Simon Jaeger

@silverleaf57 @jscholes @pitermach @BorrisInABox Yes. Throw a screen reader at a sighted developer who is on too much of a time crunch to read the manual enough to even figure out basic navigation, and suddenly that developer is throwing tab stops on static text and trying to turn the whole sight into a narrated experience instead of thinking about efficiency.