To whom it may concern:
I am writing to make you aware of some accessibility concerns I have with your new portable audio recorder, the Microtrack 24/96. Also, I have a few requests for bug fixes which I hope make it into future firmware updates for it. First, however, let me commend you on creating such a feature-rich product. Not only does it meet the needs of professional field recordists, it does so at a low price and with a form factor unmatched by the competition. The ability to record high-resolution 24-bit digital audio for less-than $500 US and in a package weighing less than 9 ounces is astounding, given the portable recorders available at the same price point only two short years ago.
As a college jazz guitar student, music teacher, performer, and frequent recorder of concerts, overall, the Microtrack 24/96 meets my needs. However, as a person who is blind, I find many aspects of the device impossible to use independently, namely the menu system and NAV control for moving between and selecting items in that menu system. I feel my concerns are valid not only for myself, but for many potential customers who are blind, especially given our need for portable audio players/recorders such as the Microtrack. Not only do many people who are blind take audio books on the go with them, but they frequently use audio recorders as a form of note taker, recording interviews, lectures, and meetings, just as sighted users do. With only a few simple modifications to the way the Microtrack’s user interface behaves, I feel this device could be rendered much more accessible to people who are blind. Additionally, it could be operated with some degree of confidence in bad lighting conditions, or from inside a pocket or carrying case by everyone!
In comparison, my previous portable recorder, a Sharp MD-MT831 minidisc recorder, had a few small features that made its behavior predictable, and with some practice, easy-to-use for those unable to see its display, or those who for various reasons, did not want to depend solely on the display while in poorly-lit environments. Most important, was a short, unobtrusive “beep” sound, audible through its 1/8” headphone output, that sounded for any button push on the unit. While this short “beep” did not change depending on operating state or which button was pushed, it at least alerted me that something had been pushed. I could then reliably count the number of beeps and button pushes, and select functions with some degree of confidence. This sound could of course be turned off, so as not to annoy users who did not require this level of feedback. With a minimal amount of memorization, I could easily select all modes and functions independently by simply counting the beeps.
Unfortunately, the Microtrack 24/96 does not make any noise whatsoever, either on bootup or shutdown, or when entering or exiting menus. Also, due to a lack of any internal moving parts, it generates no mechanical vibration that could similarly alert me to its current operating state. To even determine if the unit is in fact booted, I must press the Record button to start recording to a file, and listen through earphones for background noise or any other evidence that the unit is operating. Similarly, if I have files recorded, I don’t really know the unit is even ready to use, unless I press the menu button, then press in on the NAV control twice, to start playback of whichever file is first in the files listing. Hearing playback through headphones, I now know that the unit is on and working. This adds an extra level of uncertainty and complexity to an otherwise simple device, and one more unnecessary step to initiating recording or playing files. A short, quiet “beep” or other sound, audible through headphones or line outs and occurring once booting is completed, would signal that the unit was on and ready to play or record.
Similarly, a short “beep”, sounded each time the NAV control is actuated, would allow for more reliable navigation of the menus. Even with sighted assistance in reading the contents of the visual display, the NAV control reacts unpredictably. Sometimes, when pressed UP or DOWN, it does not activate and nothing on the display changes. Other times, it activates, but things move too far on the display – e.g. one push may result in more than one movement through menu items. Some sort of audible sound would at least alert me, and presumably other users, to the fact that the control did cause something to happen. Additionally, if the pitch of this sound changed, depending on the highlighted position in the menu hierarchy, it could help the user distinguish between available choices. For example, the “beep” for “YES” could be higher than that for “NO”, or the pitch of the “beep” could increase, corresponding to selecting a higher value in the list of available sampling rates, mp3 encoding rates, automatic shut off values, etc.
Another easily corrected accessibility barrier is how the menus on this device wrap around, making it easy to get lost. Perhaps, another adjustment that could be user-selectable, would be a “fixed menus” option, that caused the highlight to stay on the top item in a menu if the user continued to press UP on the NAV control. Similarly, the last item in a menu would remain highlighted, despite further DOWN presses on the NAV control. This would have the added benefit that, if users became lost, they would only need to press UP or DOWN until they could be certain they were on the first or last item in the menu, then with more confidence, switch direction and successfully navigate to their desired menu item.
Last but not least, these two options should be combined, and selectable by a control combination that is not display-dependent. Burying an “access mode on/off” item in the System menu, for example, would ironically, render it inaccessible, unless of course it defaulted to ON from the factory. Instead, if the user could press and hold POWER, plus another button like REC or DEL, or one of the level adjustment buttons, it could force the unit to boot up in a more accessible state.
In its current state, and using firmware 1.2.3, I must find sighted assistance to change any recording options, like selecting input source, encoder type, bit depth and sampling rate, etc. If I do not need to change these items often, I can record independently, monitoring through headphones. Anything further, and I must find someone to read the display as I navigate the menus.
Here is an alternative suggestion for improving the relative accessibility of this device. If the Microtrack 24/96 has no way to generate any sort of sound like that described above, could it’s various options be navigated and selected remotely, when the unit is connected to a computer? Since almost anybody using the recorder is theoretically going to connect to a computer to transfer files to and from the recorder, would it be possible to write a simple Control Pannel application, similar to the one bundled with your computer sound cards? I and many other blind computer users use your sound cards, like the Delta Audiophile 24/96, not just for the excellent audio performance, but because your Control Pannel application for those sound cards is 100% accessible tu us. It seems simple enough to me, a non-programmer, to adapt the Control Pannel you already developed for your sound cards, for use with the Microtrack 24/96. Although not rendering the device accessible on its own, this would at least make it fully accessible and configurable to users who are blind, so long as it is connected to a computer. Everything could be adjusted and selected independently, before taking the recorder into the field for the day.
Both the fact that your sound card Control Pannel application uses standard Windows controls, and is therefore accessible, plus the frequent updates to the Microtrack 24/96 firmware, suggest that you are a proactive company, open to user feedback and quick to fix bugs and implement new features in your products. For those reasons, I feel optimistic that an already great product can be easily made even better to be both easier to use by all, and more reliable in the field. With that in mind, I submit the following requests for future firmware updates:
First, although the Microtrack can record to large Compact Flash cards or microdrives, it has a per file limit of 2GB. That sounds like a lot, except that when recording high-resolution audio, clearly a selling point of this device, this 2GB limit is hit rather quickly. In the case of 24-bit 96KHZ .wav files, the maximum file size is reached in just under one hour! How hard would it be to start saving the current file at a predetermined distance from it’s end, and buffer incoming data as long as it takes to start recording to a new file? This kind of seemless file split seems like the easiest solution to this problem. Barring that, would it be possible to store each incoming audio channel separately, theoretically doubling the amount of record time available before the 2GB limit is reached? In other words, the two channels could be recorded simultaneously to their own unique .wav files, and by the time each of these hits the 2GB limit, a total of 4GB of stereo audio has been recorded.
Also, I cannot record reliably using the SpPDIF input using a sampling frequency above 48KHZ. I would like to be able to do this, to use an external microphone preamp and A/D converter, to bypass the noisy internal microphone preamp.
Thank you for reading my various concerns, requests and suggestions. If you have any questions about my particular situation, or about accessibility in general, please e-mail me. I look forward to future firmware updates and any bug fixes or enhancements they bring, especially any relating to the relative accessibility of the user interface. One of your compeditors’ products has more dedicated controls and menus that do not wrap around, but I chose the Microtrack 24/96 both for it’s feature set and its incredibly small size. I hope I have not chosen in error. Thank you for your time and interest.
Sincerely,
Chris Smart
Topic: Letter to M-audio: comments/criticism wanted (Read 1668 times)