Kaen's Ritus

https://colab.research.google.com/drive/16XcrmmH2NhqSpK9IC1uPpoUoegx9KZVo?usp=sharing 

https://colab.research.google.com/drive/16wtguOxFr8s9V0m1iDVk_HyJIdRAhtGP?usp=sharing 

https://colab.research.google.com/drive/1E1Wm6v_0UzL544RazYXWfbWFRv0GyXpc?usp=sharing 

https://colab.research.google.com/drive/1ithFk1Xsh6wnNcmbmrXSWq7GmjM6Oqpx?usp=sharing

https://colab.research.google.com/drive/1lP_T9dpgWk-6c0M8s8YcuF87ISMWWzVz?usp=sharing

Break

https://colab.research.google.com/drive/1dazxSnDp8eK5neDgON0pnZe1EKraOOLs?usp=sharing

LibriSpeech, Libri-Light, Multilingual LibriSpeech (MLS) 등...

나 같은 경우는 윈도우에서 다운받아서 그것을 작업 서버로 옮겨야하는,

굉장히 비효율적인 그런 행동을 자주 하곤 했다.

국내 AIHUB 데이터셋은 이런식으로 다운받아야해서 얼마나 짜증나는지 모르겠다. 

게다가 연구실에 대용량 데이터셋 다운받게 되면 전체적으로 인터넷도 느려지고,

MobaXterm으로 옮기다 보면 도중에 죽는 경우도 많아서 정말 짜증나는 일이다.

오늘 예시로 해볼것은 우분투에서 wget을 사용하여 LibriSpeech (http://www.openslr.org/12) 의 dev-clean.tar.gz 을 다운받아보겠다.

아래는 해당 사이트 그림인데

여기에서 왼쪽 최하단의 부분을 보면 주소가 제공된다.

https://www.openslr.org/resources/12/dev-clean.tar.gz 

그다음 wget https://www.openslr.org/resources/12/dev-clean.tar.gz 하면 끝난다

우분투 내 실행화면은 아래와 같다

음 정말 간단하다

이렇게 하면 3TB 짜리 Libri-Light 받는 것도 부담 없겠다.

AIHUB 데이터셋은 특정 프로그램을 이용해서 다운받아야 되는데 정말 짜증나는 일이다. 

얼른 고쳐주면 좋겠다.

음성 인식 테스크에서 pcm 파일을 direct로 읽어야 할 때가 있는데, 이 때 두 가지의 코드를 주로 사용한다.

오늘은 이에 대해 생각 정리 겸 실험 내용을 저장하기 위해 작성한다.

1. numpy memmap으로 읽을 경우

이 때에는, 읽은 pcm 파일을 그대로 저장하게 되면 음성의 magnitude가 굉장히 크기 때문에 max value인 32767로 나눠주어야 한다.

signal = np.memmap(sample_data, dtype='h', mode='r').astype('float32')

signal = signal / 32767

2. numpy frombuffer + librosa로 읽을 경우

1번과는 다르게 따로 나눠줄 필요는 없다.

with open(sample_data, 'rb') as opened_pcm_file:
    buf = opened_pcm_file.read()
    pcm_data = np.frombuffer(buf, dtype = 'int16')
    wav_data = librosa.util.buf_to_float(pcm_data, 2)

3. 음질 결과 비교 

1번:

2번: 

1번의 32767로 normalized 한 파일과 2번 방식으로 읽은 파일은 서로 데이터의 크기가 같다.

4. 변환 속도 비교

1번과 2번의 시간 비교는 아래와 같다.

2번이 약 2배 이상 빠른것을 알 수 있다.

5. 결론

두 방법 모두 가능하지만, 대규모 데이터셋을 처리하기 위해서는 2번 방법을 사용하는 것이 좋을 것 같다.

예를 들어 KoSpeech 같은 경우 각 음성 파일의 길이 비교 없이 training set 62만개에 대해서 10에폭을 돌린다고 하면

1번 방법: 620,000 * 10 * 0.00054 = 3,348 = 0.93시간

2번 방법: 620,000 * 10 * 0.00026 = 1,612 = 0.44시간

의 차이가 data loading 할 때 발생한다.

전체 코드

import soundfile as sf
import os
import numpy as np
import time

sample_data = './45.pcm'
data_dir = './check_pcm/'

start = time.time()
signal = np.memmap(sample_data, dtype='h', mode='r').astype('float32')
print(signal.shape)

signal = signal / 32767
print('method1 takes {}'.format(time.time() - start))


sf.write(os.path.join(data_dir, 'method1_16000.wav'), signal, 16000, format='WAV', endian='LITTLE', subtype='PCM_16')

import librosa
start = time.time()
with open(sample_data, 'rb') as opened_pcm_file:
    buf = opened_pcm_file.read()
    pcm_data = np.frombuffer(buf, dtype = 'int16')
    wav_data = librosa.util.buf_to_float(pcm_data, 2)
print('method2 takes {}'.format(time.time() - start))    

sf.write(os.path.join(data_dir, 'method2_16000.wav'), wav_data, 16000, format='WAV', endian='LITTLE', subtype='PCM_16')

pcm 파일의 sampling rate는 어떻게 구할 수 있을까? 다음번에는 이 문제와 관련된 issue 정리해보기

이전 포스팅에서 pytorch DDP 사용시 conda 문제로 축약되어 게시한 글이 있었다. 해당 글에서는 conda를 최신으로 업데이트하여 문제 해결을 하라고 하였으나, 직접 돌려보니 conda version 문제는 아닌 듯 하다.

그러던 도중 다른 연구자들에 따르면, python 3.8에서 이러한 문제들이 자주 생긴다고 주장되었고, 이에 대한 해결책이 python 3.7로 degrading 하여 사용하라는 것이었다.

이에 따라 나는 conda latest version에 python 3.7로 세팅하여 실행해보았지만, 같은 문제가 생겼음을 확인하였다.

이 와중에 ram memory 문제라는 것이 제기되었다. data loader를 너무 급격히 돌리다보면 system memory가 부족하여 생기는 문제라고 한다.

현재 사용중인 서버 환경은 ubuntu 18.04, memory 251G, Swp 30G, RTX 24GB x 8EA이다. 통상적으로 메모리가 512는 되어야 한다고 주장하는 것 같다.

반면에, 다른 서버 환경인 memory 126GB, Swp 30.4GB, RTX 24GB x 4EA 에서는 해당 문제가 발생하지 않았다. 즉 parallel DDP를 사용하기 위해서는 memory 혹은 Swp memory 가 더 필요한 것처럼 보일 수 있다.

혹은 사용하는 data가 커서 생기는 문제일 수도 있다.

현재 사용하는 데이터는 wav 음성을 입력으로 사용하여 pre-trained 된 feature model로 부터 약 3~5MB의 768, T 만큼의 feature를 얻고, 이것을 npy로 저장하고 있다. 이렇듯, 데이터가 커서 생긴 문제일 수도 있을 것 같다.

또한, 약 5개의 서버에서 NAS로 묶어서 sharing을 하였는데, 모든 곳에서 같은 data를 read 하다가 부하가 생긴 문제는 아닐까? 라는 생각이 들었다.

하지만 추측하건대, system memory를 늘리면 해결가능한 문제인 것으로 보인다.

요약

1. pytorch DDP 문제 발생

2. conda update 시도 하여 문제 해결 --> 실패

3. python 3.7 버전으로 degrading 하여 문제 해결 --> 실패

4. 결론: system memory 추가 필요