📄 Design of a Tigrinya Language Speech Corpus for Speech Recognition

Summary

Tigrinya, a Semitic language of the Horn of Africa, had no dedicated speech corpus for building automatic speech recognition (ASR). The authors designed and recorded one. They followed published corpus-construction guidelines, mainly Li & Zu (2006), and copied the component layout of the Amharic speech corpus. The text side is 10,000 sentences chosen to be syllabically and phonetically rich and balanced, so that every contextual syllable and phone of Tigrinya appears. A total of 130 native speakers, spread over age bands, both sexes, and Northern and Southern dialects, read the prompts on phones and tablets. Recording used the Android app Lig-Aikuma, with a researcher present to replay and re-record any faulty utterances. The data are split into four parts: a training set (about 18 hours), a speaker adaptation set, a development test set and an evaluation test set. Background noise conditions vary across recordings. The paper reports no recognition results. Its value is a first reusable ASR resource for an under-resourced language and a design recipe that others can follow.

Key points

• 130 speakers in total. The training set has 100 speakers (54 male, 46 female), the test set 10 and the adaptation set 20, grouped into six age bands from 18 to 70. Children and people over 70 were excluded because their speech would need separate acoustic models.
• Training uses 10,000 distinct recorded sentences (17:57 h). Adaptation uses 69 sentences (2:30 h). The dev and eval sets each drew 1,000 candidate sentences, of which 600 (2:10 h) and 400 (1:20 h) were recorded.
• Audio is 16 kHz with 16 bits per sample. Noise conditions include office, street and in-car, with SNR mostly 20–85 dB. Overlapping speech is excluded.
• Recording used an improved Lig-Aikuma (Blachon et al., 2016). It stores speaker and language metadata, preloads the previous session's metadata, and names files by date, time, device and language code (e.g. _tir).
• The prompts are in literary (formal) Tigrinya, read by speakers of different dialects. The authors plan to release the corpus through a third party.

Interesting ideas

• I1. Prompt sentences were selected so the whole inventory of contextual units (syllables, phones) is covered and balanced, rather than sampled at random, which gets coverage with few sentences.
• I2. The corpus mirrors the standard layout of a comparable corpus (training, adaptation, dev test, eval test), with distinct sentences per test speaker, so results stay comparable and test material never leaks into training.
• I3. Every utterance is checked on the spot by the speaker and the researcher and re-recorded if wrong, which catches errors while fixing them is still cheap.
• I4. Provenance (speaker, language, device, time) is saved alongside each recording and even encoded in the file name, with earlier values preloaded to save effort.
• I5. Noise conditions are deliberately varied and SNR is tracked, so models are robust and evaluation can be broken down by condition.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (tree): Choose sentences for a new or converted treebank so they cover every UD relation and rare construction in balanced amounts, giving the parser examples of each pattern rather than mostly frequent ones.
• I2 (learn): Keep a fixed split of training, domain-adaptation, dev and held-out eval data, with no shared sentences, so that gains from silver data or repair rules are measured honestly.
• I3 (learn): Validate each silver tree or LLM-teacher label as soon as it is produced and send failures back for regeneration, rather than cleaning a large batch afterwards.
• I4 (learn): Attach source, witness parsers, teacher tier and timestamp to every training example, so a bad example can be traced back to the component that produced it.
• I5 (answer): Build test sets with tagged levels of text difficulty (typos, informal style, long sentences) and report accuracy for each level, so a readers' failures can be tied to specific input conditions.