yyeennyy commented 1 year ago

Issue

split2 모듈의 split_music() 메서드 검토 요청

Detail

문제를 발견했습니다. split_music() 메서드의 인풋 파라미터와 과정을 재검토해야 할 것 같습니다. 파라미터로 들어오는 건 split된 오디오, sr, not_ment입니다.

wav = sec_wav_list[idx][1]
music_range = split_music(wav, audio_holder.sr, not_ment)

로그 기반으로 설명을 잇겠습니다.

not_ment는 이렇게 뽑힙니다.

not_ment : [[0.0, 35.5], [76.0, 243.0], [300.0, 335.5], [376.0, 543.0], [680.0, 721.0], [766.5, 900.0]]

split_music의 시작! 여기서부터 유의해주세요.

visual-radio  | 2023-09-11 02:06:38 |DEBUG| services.py:284 ...  services > [split_cnn] sec_0.wav split ment 끝, split_music 시작

다음은 def split_music(y, sr, not_ment) 파라미터 중 y의 길이입니다.

visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:280 ...우리가1등(^o^)b > input audio: 14632945

이제부터 각 not_ment를 돌면서 music_lst에다가 음악구간을 추가해나갑니다.
이때 마지막 not_ment의 start, end 범위가 y의 길이를 넘어서는 문제를 발견했습니다.
로그를 찍어보았습니다.

[0.0, 35.3] 구간 (진행완료!)


visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:284 ...우리가1등(^o^)b > not_ment : [0.0, 35.5]
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:287 ...우리가1등(^o^)b > start, end 이상 체크!
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:288 ...우리가1등(^o^)b > 0.0 <-start
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:289 ...우리가1등(^o^)b > 35.5 <-end
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:290 ...우리가1등(^o^)b > 0
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:291 ...우리가1등(^o^)b > 782775

참고) 아래 두 줄인 0, 782775는 start, end에 각각 sr을 곱해준 값입니다.
이어서 봅시다..

[76.0, 243.0] 구간 (진행완료!)

visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:284 ...우리가1등(^o^)b > not_ment : [76.0, 243.0]
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:287 ...우리가1등(^o^)b > start, end 이상 체크!
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:288 ...우리가1등(^o^)b > 76.0 <-start
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:289 ...우리가1등(^o^)b > 243.0 <-end
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:290 ...우리가1등(^o^)b > 1675800
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:291 ...우리가1등(^o^)b > 5358150

[300.0, 335.5] 구간 (진행완료!)

visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:284 ...우리가1등(^o^)b > not_ment : [300.0, 335.5]
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:287 ...우리가1등(^o^)b > start, end 이상 체크!
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:288 ...우리가1등(^o^)b > 300.0 <-start
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:289 ...우리가1등(^o^)b > 335.5 <-end
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:290 ...우리가1등(^o^)b > 6615000
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:291 ...우리가1등(^o^)b > 7397775

[376.0, 543.0] 구간 (진행완료!)

visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:284 ...우리가1등(^o^)b > not_ment : [376.0, 543.0]
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:287 ...우리가1등(^o^)b > start, end 이상 체크!
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:288 ...우리가1등(^o^)b > 376.0 <-start
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:289 ...우리가1등(^o^)b > 543.0 <-end
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:290 ...우리가1등(^o^)b > 8290800
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:291 ...우리가1등(^o^)b > 11973150

문제의 구간!!
파라미터 y (즉 인풋 오디오)는 길이가 14632945입니다.

그런데 아래 start, end를 보시면 14994000가 start고 15898050가 end입니다.

visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:284 ...우리가1등(^o^)b > not_ment : [680.0, 721.0]
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:287 ...우리가1등(^o^)b > start, end 이상 체크!
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:288 ...우리가1등(^o^)b > 680.0 <-start
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:289 ...우리가1등(^o^)b > 721.0 <-end
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:290 ...우리가1등(^o^)b > 14994000
visual-radio  | 2023-09-11 02:06:38 |DEBUG|   split2.py:291 ...우리가1등(^o^)b > 15898050

그래서 담당자님께 검토 요청합니다.

yyeennyy commented 1 year ago

부연설명: 이렇게되면 이후 seg의 length가 0이 되기 때문에 오류입니다.

shxnzxxn commented 1 year ago

확인했습니다! 이전에 배열로 음성 처리를 하면서 저도 이런 오류를 발견해서, 해결했습니다.

문제의 원인은 두 가지로 볼 수 있었는데,

입력으로 들어온 sr과 mr 제거된 sr이 다르기 때문. 길이는 같지만 sr이 달라서 구간이 다르게 나옴.
mr을 제거하고, 음성을 합치는 과정에서의 로직에서의 오류

이 두 부분을 모두 수정했는데, 아직 남아있다니.. 전처리 한번 돌려보고 확인해보겠습니다.

shxnzxxn commented 1 year ago

그러니까 정확히는 split_music이 아니라, 애초에 mr 과정에서 오류가 났던 것으로 확인이 되었는데.. 한번더 확인해보겠습니다. 감사합니다.

yyeennyy commented 1 year ago

순차처리 vs 병렬처리 문제임을 발견했습니다.

순차처리시 정상 기능이나, 저희 서버에서 병렬처리가 잘 되는 상태이므로 로직을 변경해야 하는 부분을 발견했습니다.

이로써 제 담당이 되었으므로, 오늘 9월 11일, 일부 코드 수정 후 PR하겠습니다.

yyeennyy commented 1 year ago

병렬처리 변경사항도 문제점이었으나 원인은 아니었습니다.

진짜 원인!

원인은 "spleeter의 오디오 처리가 하나씩 밀린다" 입니다. (로그 참고)

[mr제거] sec_0-0.wav.. 오디오 길이 6615000
[mr제거] sec_0-0.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_0-0.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_0-1.wav.. 오디오 길이 6615000
[mr제거] sec_0-1.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_0-1.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_0-2.wav.. 오디오 길이 1402945
[mr제거] sec_0-2.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_0-2.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_1-0.wav.. 오디오 길이 6615000
[mr제거] sec_1-0.wav.. 추출된 vocals 길이 1402945
[mr제거] sec_1-0.wav.. 만들어진 mono_data 길이 1402945

[mr제거] sec_1-1.wav.. 오디오 길이 6615000
[mr제거] sec_1-1.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_1-1.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_1-2.wav.. 오디오 길이 6615000
[mr제거] sec_1-2.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_1-2.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_1-3.wav.. 오디오 길이 3738047
[mr제거] sec_1-3.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_1-3.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_2-0.wav.. 오디오 길이 1421136
[mr제거] sec_2-0.wav.. 추출된 vocals 길이 3738047
[mr제거] sec_2-0.wav.. 만들어진 mono_data 길이 3738047

[mr제거] sec_3-0.wav.. 오디오 길이 6615000
[mr제거] sec_3-0.wav.. 추출된 vocals 길이 1421136
[mr제거] sec_3-0.wav.. 만들어진 mono_data 길이 1421136

[mr제거] sec_3-1.wav.. 오디오 길이 6615000
[mr제거] sec_3-1.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-1.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_3-2.wav.. 오디오 길이 6615000
[mr제거] sec_3-2.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-2.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_3-3.wav.. 오디오 길이 6615000
[mr제거] sec_3-3.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-3.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_3-4.wav.. 오디오 길이 6615000
[mr제거] sec_3-4.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-4.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_3-5.wav.. 오디오 길이 1513702
[mr제거] sec_3-5.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-5.wav.. 만들어진 mono_data 길이 6615000

[mr제거] sec_4-0.wav.. 오디오 길이 4948548
[mr제거] sec_4-0.wav.. 추출된 vocals 길이 1513702
[mr제거] sec_4-0.wav.. 만들어진 mono_data 길이 1513702

왜 이러나요?

보면, 새로운 오디오를 mr처리했는데도 이전 오디오가 처리결과로 리턴되는 상황입니다. 예상하기로는, 오디오 배열이 크기 때문에 어디선가 생기는 딜레이같습니다. 새로운 오디오 배열이 separate(audio)로 넘어갈 때, 해당 spleeter개체의 어디엔가 이전 오디오가 아직 남아있어서 그것을 처리하게 되는 걸까요? 일단! 그렇게 생각해보겠습니다.

이때 두가지 해결방안을 생각해보았습니다. 방법1) 하나의 오디오배열 처리 완료 후 spleeter 객체 초기화 방법2) time.sleep(..) 을 적당히 둬서, spleeter객체가 이전 오디오 배열을 separate하는 일이 없도록 해보기.

방법1을 먼저 시도했는데 해결이 되었습니다. (기분조흠) time.sleep()을 두는 시도는 안 하려고 합니다. 몇초 쉴지도 애매하고, 방법1보다 확실한 방법도 아니라서요! 아래 로그를 통해 정상적으로 바뀐 결과를 확인하시죠호~

[mr제거] sec_0-0.wav.. 오디오 길이 6615000
[mr제거] sec_0-0.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_0-0.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_0-1.wav.. 오디오 길이 6615000
[mr제거] sec_0-1.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_0-1.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_0-2.wav.. 오디오 길이 1402945
[mr제거] sec_0-2.wav.. 추출된 vocals 길이 1402945
[mr제거] sec_0-2.wav.. 만들어진 mono_data 길이 1402945
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_1-0.wav.. 오디오 길이 6615000
[mr제거] sec_1-0.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_1-0.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_1-1.wav.. 오디오 길이 6615000
[mr제거] sec_1-1.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_1-1.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_1-2.wav.. 오디오 길이 6615000
[mr제거] sec_1-2.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_1-2.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_1-3.wav.. 오디오 길이 3738047
[mr제거] sec_1-3.wav.. 추출된 vocals 길이 3738047
[mr제거] sec_1-3.wav.. 만들어진 mono_data 길이 3738047
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_2-0.wav.. 오디오 길이 1421136
[mr제거] sec_2-0.wav.. 추출된 vocals 길이 1421136
[mr제거] sec_2-0.wav.. 만들어진 mono_data 길이 1421136
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_3-0.wav.. 오디오 길이 6615000
[mr제거] sec_3-0.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-0.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_3-1.wav.. 오디오 길이 6615000
[mr제거] sec_3-1.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-1.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_3-2.wav.. 오디오 길이 6615000
[mr제거] sec_3-2.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-2.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_3-3.wav.. 오디오 길이 6615000
[mr제거] sec_3-3.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-3.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_3-4.wav.. 오디오 길이 6615000
[mr제거] sec_3-4.wav.. 추출된 vocals 길이 6615000
[mr제거] sec_3-4.wav.. 만들어진 mono_data 길이 6615000
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_3-5.wav.. 오디오 길이 1513702
[mr제거] sec_3-5.wav.. 추출된 vocals 길이 1513702
[mr제거] sec_3-5.wav.. 만들어진 mono_data 길이 1513702
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

[mr제거] sec_4-0.wav.. 오디오 길이 4948548
[mr제거] sec_4-0.wav.. 추출된 vocals 길이 4948548
[mr제거] sec_4-0.wav.. 만들어진 mono_data 길이 4948548
[mr제거] 완료되었습니다. spleeter객체를 초기화해볼게요!

yyeennyy commented 1 year ago

다만 이제는 OOM이 납니다. 연이은 다음과정인 cnn 모델 돌릴 때 말이죠. gpu 정리하는 과정을 추가해야겠습니다.

shxnzxxn commented 1 year ago

splitter 객체를 초기화한다면, 혹시 모델을 다시 다운받는 과정이 있나요??

추가적으로, 쓰레드로 진행하지 않고 함수를 호출함으로써 진행해보는건 어떨까요?? 만약 쓰레딩에서 문제가 생길 수도 있을 것 같다는 생각을 했습니다. 제가 gpu를 사용할 수 있는 환경이 아니라서, 확인을 못해보네요... (저희 서버에서 돌려볼까요?? OOM은 해결 됐을까요??)

p.s. 해결 되기만을 바라서 죄송합니다 ㅠ

yyeennyy commented 1 year ago

모델을 다시 다운받는 과정은 없습니다. 지연없이 빠르게 다음 작업으로 넘어갑니다!
이번 pr에는 제가 gpu부분을 배제했습니다! 앞으로 깃헙에는 gpu환경 코드는 비활성화(주석처리)해서 올릴 예정입니다 ㅎㅎ 만약 기존의 멀티프로세싱 혹은 멀티쓰레딩을 돌릴 때에도 역시 새로운 spleeter객체를 할당해야 문제가 없을 것 같습니다. 기존 코드에서 각 프로세스에서 동일한 spleeter객체를 사용했는데요, 프로세싱 start 전에 보면 wav 할당 후 start를 외칩니다. mr_remover.wav = wav_reshape mr_remover.start() 의도대로라면 wav가 할당되고 나서 start()를 외쳐서 spleeter 작업에 들어가야 하는데, Remover객체는 이전 wav를 가지고 작업을 합니다. 그래서 제가 sleep을두거나 spleeter객체를 새로 둬야 한다고 생각했던 것입니다. 혹시 병렬처리가 의심되는 부분이 있다면 의견듣고 다시 한 번 생각해보겠습니다!!
OOM은 미해결입니다. 이건 gpu문제인데, cpu에서 돌리면 이번 이슈는 문제 없을 것입니다.

p.s. 제 일인데여!! 저는 좋아요!

shxnzxxn commented 1 year ago

오!! 감사합니다!!
gpu 환경 코드를 주석처리해서 올리는 것보다, 배포 브랜치를 따로 두고 진행해보는 것은 어떨까요??
OOM ㅠㅠㅠ 응원하겠습니다.

yyeennyy commented 1 year ago

좋은 방법 제안 감사합니다! ㅎㅎ gpu이슈는 따로 남겨두었습니다. 거기에 언급했지만, cpu-gpu 환경 스위치 방법은 우선순위 이슈 해결 후 진행할 예정입니다!

yyeennyy / VisualRadio

problem_with_split_music_method #139

Issue

Detail

진짜 원인!

왜 이러나요?