Y'all are really pushing my brain, thank you!
That's a good idea and might be the way to go if it's really critical that no part of the question is missed. My immediate reaction is that it would be pretty disruptive. As an alternative, documentation could suggest things like starting the recording one or more questions before what's really important and ending after. We can also show example forms with a screen that asks the data collector to acknowledge that the next N questions will be recorded and/or get consent (like our foreground recording demo form). For Collect, we can also suggest disabling settings for moving backwards and going to the jump view to force fully linear navigation through the form. Using documentation this way would allow for more flexibility depending on the context.
We could. The special thing about audit that I don't think would be the case for any other kind of automatic background population is that there can only ever be one. So it feels ok that it has its own special spec.
But if consistency is really important there, it should be ok for Collect to support both the fixed audit name in orx:meta and a specific attribute that applies to binary fields without a body element anywhere in the form (e.g. odk-audit=true or maybe even odk-background-populate=audit). We could do what we've done before and eventually shift docs and pyxform to the preferred spec. I think that approach can address the multiple-file requirement: we can allow any number of fields with the attribute. That would also be fine with audit, we'd just say that all would be populated with the same filename (same as with background audio without a range specified).
Here's another concept tying in various parts of the conversation above. It sounds like we generally like an action for the case of a single recording that captures everything. Perhaps we could do that and introduce the artificial restriction that it can only be triggered by xforms-ready (and thus can't nest in the body).
<odk:recordaudio event="xforms-ready" ref="/data/my_recording" odk:quality="low"/>
I've used odk:recordaudio instead of odk:startrecording with a type like above because I now think it's easier to read and more coherent with implementation. I can't imagine that e.g. audio recording and video recording would be able to share a lot in any platform, even less so other types of data we've discussed like humidity readings.
For recording only in a question range, we could specify attributes on the action:
<odk:recordaudio event="xforms-ready" ref="/data/my_recording" odk:quality="low" odk:start="/data/q1" odk:end="/data/q13" />
This would mean "start the recording engine when the form loads and actually record audio when the enumerator is interacting with a question between /data/q1 and /data/q13 inclusively." Alternately, as came up in conversation with @Xiphware above, it could mean "start the recording engine when the form loads if and only if /data/q1 and /data/q13 are questions displayed on their own screens (otherwise ignore the whole thing). Actually record when a question between /data/q1 and /data/q13 inclusively is on screen."