HuggingFace Datasets Audio에서 이제 pcm을 지원합니다.

최근에 HuggingFace Datasets 중 Audio 부분에서 Contribute를 진행했습니다.

KsponSpeech의 경우, Training Dataset이 PCM으로밖에 존재하지 않습니다.

HuggingFace를 사용하던중 마침 Audio가 있길래 사용해보니, PCM은 지원이 되지 않더군요

https://github.com/huggingface/datasets/issues/4323

Audio can not find value["bytes"] · Issue #4323 · huggingface/datasets

이유는 기존에 개발된 소스가 Header정보를 포함하고있는 mp3 혹은 wav 등과 같은 데이터거나, 혹은 스트리밍처럼, Bytes로 넘어온 데이터만 활용 가능했기 때문입니다.

PCM의 특징은 Header가 없으므로, 위와 같은 load방법을 사용하면, 데이터의 변형이 생깁니다.

Kaen 님의 블로그를 보면 비슷한 내용을 다룬 글이 있는데,

https://kaen2891.tistory.com/107#comment6484678

pcm file reading 관련 issue 와 비교

여기서의 댓글은 값이 조금 달라지더라도 같은 방식만 유지하면 크게 상관 없을 것 같다는 피드백이었습니다.

(물론 학습 시에는 그럴 것도 같습니다.)

 

다만, 저는 원본값이 변형될 여지가 있다는 부분에서, 특히나 HuggingFace라는 많은 사람들이 사용하는 오픈소스에서 이런 문제가 발생한다는 것은 조금 위험의 여지가 있다고 판단하였고, PCM을 지원하기로 마음먹어서.

 

https://github.com/huggingface/datasets/pull/4409

Update: add using pcm bytes (#4323) by YooSungHyun · Pull Request #4409 · huggingface/datasets

위와 같은 절차의 소스들을 수정하여 해결하였습니다.

큰 수정사항은 이렇습니다.

PCM의 경우 헤더가 없으므로, 샘플링 레이트 정도는 필수로 받아와야 합니다. 때문에 샘플링 레이트를 받고, 파일이 pcm인 경우, 과거의 Fairseq에서 pcm bytes를 계산했던 방식을 차용하여 pcm의 float byte를 계산하고, wav format으로 byte 변환합니다. 즉, PCM을 불러다가 최소한의 wav인 것 처럼 byte로 저장하는 방식을 차용했습니다.

(해당 방식은 최근 Fairseq에서는 수정되었어서, memmap을 사용하여 나누기 32767을 하는 방식은 더 이상 사용되진 않습니다. 때문에 방식을 개선하거나 최신 방법론으로 사용하는게 더 나을 지도 모르겠어요)

 

이렇게 처리되면 사실상 이후 과정에서는 wav와 다를게 없으므로, decode_example에서 추가적인 수정 소요는 없게됩니다.

 

제가 PR을 날린 부분에서, sako가 헤더가 없는 것에 대한 의문을 단 것에 대한 반박과, 실제로 soundfile등을 썼을때의 실질적인 값의 차이가 어떻게 발생하는지 증명해놓은 부분들도 있으므로, 음향쪽 data를 다루신다면 한번 읽어보시는 것도 좋을 것 같네요

git pr의 내 댓글 일부

PCM을 다룰 수 있는 효과적인 방법이 있다면 손쉽게 contributor 뱃지를 다실 수도 있게 될지 모르니 일단 공유해놔 봅니다....ㅎㅎ

 

저도 시간이 된다면 다시 재기여 도전하겠습니다.