Recording that are split into multiple files

[LoannPeurey]

Is your feature request related to a problem? Please describe.
It is a common occurence that recorders will split the recordings into multiple audio files. When this happens, previous practice has been to either:

• keep all the audio files and record them as different recordings, having their starting time begin when the previous one ends. The problem is that the timeline is broken (this is ok for metrics because we can use session_id, but for sampling periodicly for example, this can't work, a problem for conversation annotations as well)
• merge the audio files into one. This approach goes against the principle of storage of original audios as they were collected (which is important so that we always hae the original in case something goes wrong with the converted versions, and conversions and changes won't result in any information loss as we have the originals

Describe the solution you'd like
Maybe it would make sense to have recordings in the metadata that actually can be a bunch of audio files together, or a piece of an audio file (can be useful in some recorders that put multiple days in the same audio), (or even a bunch of pieces from multiple audio files). And then a conversion function would create a converted single audio file from those. The problem is that the 'recording_filename' in recordings.csv is used as a primary key and this way of doing things would cause issues with this

More thinking and experiments needed

[lucasgautheron]

I do not think systematically merging is a good option. First, the core issue would no longer be transparent. Having split audios at least makes it explicit that there might be gaps in between. Of course, people are free to decide to merge split recordings into single audios and then reference those in the metadata. But then they are responsible for their own mistakes, if they perform any operation that does not account for the actual gaps. Plus, if you reference merged audio in the metadata: how do you keep track of all the breaks and gaps within the audio? This might become even harder to manage. For instance, then, how do you write the piece of code that samples annotations between certain hours? With the current scheme this is very straightforward (but of course the results are reliable only if recordings are not merged).

To put it briefly: I think that such a limitation in the data (gaps in the audio) should appear very explicitly. This can prevent many mistakes.

Regarding sampling and conversations: am I wrong that these features could also support session_id if necessry (although it should not be the default behavior, probably)? The only obstacle I see is the lack of accuracy of start_time; it's measured at the second level at best. But for more (if not all) case-scenarios this should not matter.

[LoannPeurey]

I think you are right, the problem of sampling and deriving metrics from conversations across the same session does not call for that much complexity to be added.
Adding support for session_id for sampling should work fine (despite the start time not always being very precise).
Conversations metrics should work the same, a small limitation is the fact that every jump in recording file will cut the interaction sequence but this has most likely small impact and is better than assuming continuity (without gaps).

More generally, everything the package does across recordings should have the option to be done by session_id