I am in the process of converting my MEG dataset to BIDS format using MNE-BIDS. A particular challenge I’m facing is with empty room (ER) recordings. My experimental paradigm involves two ER recordings per session: one before and one after each participant’s recording session.
I’ve attempted to incorporate these multiple ER recordings by using the task-noise_run-01, task-noise_run-02, etc., naming convention for the ER files, as suggested in the discussion around issue #1373 (specifically, the comment multiple empty room recordings · Issue #1373 · mne-tools/mne-bids · GitHub).
However, I’ve encountered limitations when trying to link these multiple ER recordings to the main experimental data:
write_raw_bids(empty_room=...): This parameter appears to only support a single Raw object or path for the empty room recording. Passing a list of Raw objects (e.g., empty_room = raw_er_list) does not work, which is understandable given the current implementation.
update_sidecar_json(bids_path, {"AssociatedEmptyRoom": er_list}): While I can manually update the _meg.json sidecar file to include a list of ER paths under the AssociatedEmptyRoom field, the BIDS validator subsequently flags this as an error. This indicates that, as per current BIDS validation rules (or MNE-BIDS’s interpretation), only a single empty room recording is officially supported as a direct reference via this field.
This limitation means it’s currently not possible to directly associate multiple pre- and post-session empty room recordings within the BIDS structure in a validator-compliant way.
My questions to the MNE-BIDS team are:
Would it be feasible to add native support within mne_bids.write_raw_bids (and potentially mne_bids.BIDSPath.find_empty_room()) for handling multiple empty room recordings ?
In the interim, what is the recommended best practice for datasets with multiple empty room recordings per session? Should we simply choose the “most representative” (e.g., the first) empty room recording for the AssociatedEmptyRoom field and store the others as task-noise recordings without explicit linking? Or is there another BIDS-compliant approach that I’m overlooking?
Thanks for the fast reply. The issue is related, but my problem is slightly different: I’m suggesting a way to manage multiple empty room recordings per subject , regardless of whether they’re stored in sub-emptyroom or as task-noise .
This could, in principle, also be achieved within sub-emptyroom by refining the session data to include not just the day, but also hours and minutes . This would allow multiple empty room recordings to be stored within a single day.
Unfortunately, I’m not familiar enough with the MNE-BIDS implementation to implement this myself right now due to time constraints.
according to the BIDS specification, your use case should be supported by specifying an array of paths to empty-room recordings in the AssociatedEmptyRoom field.
Name: Associated Empty Room
Type: Metadata
Description: One or more BIDS URIs pointing to empty-room file(s) associated with the subject’s MEG recording. Using forward-slash separated paths relative to the dataset root is DEPRECATED.
This means that we actually should enhance MNE-BIDS to support this – we’re currently not standard-compliant there! Would you be interested in helping out to add or at least test this?
@sappelhoff I could imagine implementing the writing part of this; I think for reading / discovering the empty-room recordings, we’ll need to discuss the API and we might even need a deprecation cycle.
@TicTacTill Would just being able to write multiple ERs, without the possibility to automatically re-discover them, already help you? (i.e., you could manually construct the correct BIDS path to the ERs as you need them when you want to read them back)
@richard Yes, it sounds like being able to write multiple ERs, even without automatic rediscovery, would already help me. My primary need is to correctly format and store this data in a way that passes the validator, even if I have to manually retrieve it later.
This is currently too far from my day to day work to offer anything but high level reviews and guidance, but I would be happy to welcome such improvements to mne-bids.
I have actually never worked with MEG data beyond playing with examples.
@richard if you have time and a plan how to do it, perhaps you could give it a shot