@felixbur pointed out that crema-d has a lot of tables as we encode train, dev, test splits in the name of the table. This has certain adavantages as you just need to load the table and you are done, but it also has the disadvantage that it makes it more crowded when look at which tables are available and requires more disk space and time for loading the tables.

The issue also applies to other datasets.

One solution might be that we store the splits in different tables, e.g. emotion.train that only contain an index (only unofficially supported by audformat at the moment) or contain another label lile speaker ID, even though the label has not really any meaning for this table. The actual emotion labels would be stored in a combined table, e.g. emotion.categories.desired instead of emotion.categories.desired.train, emotion.categories.desired.dev, and emotion.categories.desired.test. If the dev split should be requested you need to do something like this:

df = db["emotion.categories.desired"].get(index=db["emotion.dev"].index)

I think we had this discussion a few years ago already, but I cannot remember what the conclusion was ;)

A more elegant solution seems to me to extend audformat to have the category of split-tables, or maybe better change how audformat.Split is implemented and store the underlying index as part of the split. A user would then be able to do:

df = db["emotion.categories.desired"].get(split="emotion.dev")

The problem is of cause that we should not change the behavior of audformat.Split() in a not backward compatible way.

@ureichel @audeerington @schruefer any opinion on this?