facebookresearch/fairseq

For `FileAudioDataset`, allow manifests to specify short segments of longer audio files

Open

#3962 aperta il 15 ott 2021

Vedi su GitHub
 (2 commenti) (0 reazioni) (0 assegnatari)Python (6224 fork)batch import
enhancementhelp wantedneeds triage

Metriche repository

Star
 (29.107 star)
Metriche merge PR
 (Nessuna PR mergiata in 30 g)

Descrizione

🚀 Feature Request

During wav2vec training, I'd like the ability to pull short segments of audio from a long audio file.

Note: I wanted to use it already, so if this is interesting, please have a look at an implementation of this proposal in rcgale/fairseq.

Motivation

Currently, I only see a way to read entire .wav files when loading audio from a manifest. This adds the burden of pre-segmenting audio using a separate tool. This is time- and space-consuming, especially when I'm experimenting with data/segmentations which are being updated frequently, and my source audio files are an hour or two long.

Pitch

The FileAudioDataset and SpeechToTextDataset classes support a manifest filename format for .zip files. Using that precedent, the manifest could be formatted like so:

/path/to
/path/to/audio1.wav:0:16000    16000              # (new format) audio1.wav, frames 0 through 16000
/path/to/audio1.wav:32000:16000    16000          # (new format) audio1.wav, frames 32000 through 48000
/path/to/audio2.wav    16000                      # (existing format, bw compatible) audio2.wav, frames 0 through end
/path/to/collection1.zip:5000:10000    64000      # (existing format, bw compatible) collection1.zip, bytes 5000 through 10000, frames 0 through end  

Alternatives

Adding an optional offset to the end of the columns was my other thought. Since size is already in the manifest format, the above format is a little redundant, but I thought the :offset:length precedent was solid for how .zip files are currently handled. Also, I don't think users expect the existing size column to be very consequential—it's only for collation I assume—so if it were suddenly cutting samples short or over-reading the buffer, that sounds like trouble.

Additional context

Thanks for wav2vec2.0! Personally, I think it's a very good algorithm, and it might go big places 😉

Guida contributor