facebookresearch/fairseq

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

Open

#3,962 opened on 2021幎10月15日

GitHub で芋る
 (2 comments) (0 reactions) (0 assignees)Python (6,224 forks)batch import
enhancementhelp wantedneeds triage

Repository metrics

Stars
 (29,107 stars)
PR merge metrics
 (30d に merged PR はありたせん)

説明

🚀 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 😉

コントリビュヌタヌガむド