What to do with ALICE now that VTC 2.0 is nearly out?

[alecristia]

We are close to releasing publicly a new version of VTC that outperforms the VTC released in 2020 (henceforth vtc 1.0). ALICE was developed based on VTC 1.0, meaning that all of the parameters were optimized taking into account vocal segmentation by VTC 1.0. The question is raised about what to do with ALICE in our datasets. I can see the following options:

1. Remove the "old" alice annotations.
2. Leave the "old" alice annotations but add in a few places (e.g., in the README, metannots, annotations.csv, the alice folder itself) a reminder that it is based on vtc 1.0 segmentation, so they are a match with the vtc annotation folder. This will reduce people's confusion.
3. Apply vtc 2.0, then use these boundaries to feed alice. This could work but it would mean having to re-evaluate ALICE, since the system was optimized for vtc 1.0.
4. Retrain ALICE with the new boundaries, and while at it, re-write it. After all, this was an old idea (the current pyALICE is a "translation" from matlab). This is a whole new research project. I feel that people are moving away from automated word count.

Any others I'm missing? Other arguments or counter-arguments?

@LoannPeurey @alix-bourree

[alecristia]

Asked about option 4, @orasanen said the following:

What we can do is that:
a) We can tell people to use durations from VTC2.0 (does it produce summary outputs across whole the recordings for different speakers, akin. to LENA AWC?).
b) ALICE repository can be added with a note pointing to VTC2.0 as the preferred solution.

If sufficiently many people would still prefer counts of (pseudo)units other than duration of speech, ALICE would need to be retrained for VTC2.0 front-end. Or, minimally, evaluated on a wide range of corpora with the new front-end but keeping the rest of the pipeline the same, and hoping that it produces more accurate estimates.

Note that the latter would entail access to human-transcribed datasets, which LAAC has for a few languages.

[alecristia]

My own preference is option 2, since I'm really motivated for a sort of "freezing" of datasets. Option 1 seems like a loss; as Okko says, options 3 and 4 require ML work that is not needed for exelang (since exelang isn't based on word count estimates)