Depends on the workflow expected. If there's a really consistent expectation among the people using this specific app, then use that reference.
For example, if you're targeting people doing medical transcription's, and the industry standard is to collect metadata up-front (because that's what people in medical offices tend to do), then front-load the metadata. Pareto's Principle (80/20 rule) is a good rule of thumb when looking at this kind of pattern (even if not exactly what he had in mind). If 80% of of the users interviewed front-load work, then it's probably a good idea to design the application to match this expectation.
However, if the split is not as well defined (e.g., 60/40) or you're targeting a broader audience, then it's better to offer some flexibility. For example, if the target of the app is salespeople recording information about a meeting, then it might be better to allow BOTH front-loading or back-loading information to afford different situations and work methods. In one instance, it might be better to quickly record the information while it's fresh after leaving the meeting, then go back and add metadata after getting to the hotel. Other instances, it may be easier to preload the metadata before the sales meeting in the first place (meaning you have a metadata record with NO recording for some period of time). Both are valid ways to work, so long as required information is collected before reaching the next step in the workflow.
Generally, I try to accommodate flexibility in these kinds of workflows so long as it doesn't introduce more complex mental models or UI. In the past, I've even developed secondary workflows that would automatically trigger on condition to ask for missing metadata after the fact. So, the flow might look something like this...
- Drop the person into a simple recording UI to start the core process, but have a reasonable, secondary affordance to add one or two key metadata (e.g., title/purpose, participants, etc.). NOTE: Some metadata is easy to automatically capture such as timestamps, current user, etc. Depending on what you're trying to do it might be possible to capture possible participants based upon the recording (although voice recognition like this is pretty hit and miss right now). I wouldn't rely upon it, but it'd be nice to suggest something. "Sounds like Rose Tyler and Amy Pond, is that correct?"
- Once the recording is complete, promote the secondary affordance for metadata to something more primary. If really important, you can promote with red/warning information.
Lastly, be sure to consider time in the workflow. As a couple of these examples have hinted, saving drafts frequently and automatically is probably a good idea. Furthermore, even if the metadata is ultimately required, look at WHEN the metadata is consumed in the larger workflow. It's easier to make a field required for a DB, but people are typically a bit more complicated and sloppy in processes.
Longer answer than I intended, but you should consider the situations and stakeholders specific to your needs. Without context, I'd suggest trying to allow both adding metadata before and after the recording. Even by creating several "empty" recordings that just have metadata, or having several recordings with partial or missing metadata that need to be completed before whatever happens next.