decodeAudioData (WebAudio API)에 대해 '유효한 mp3 청크'를 정의하십시오.

Question

decodeAudioData를 사용하여 javascript에서 더 큰 mp3 파일의 초기 부분을 디코딩하고 재생하려고합니다. 내 첫 번째, 원시, 접근 방식은 mp3의 시작 부분에서 여러 바이트를 잘라내어 decodeAudioData에 제공하는 것이 었습니다. 당연히 이는 실패합니다.

일부 파기 후에는 decodeAudioData가 Fair Dinkum Thinkum, here에 문서화 된 '유효한 mp3 청크'에서만 작동 할 것으로 보입니다.

그러나 유효한 mp3 청크의 구조에 대한 설명이 없습니다 (앞에서 설명한 작성자는 여기에 포함되지 않습니다). 나는 거기에 존재하는 다양한 MP3 스플리터를 알고 있지만 이것을 프로그램 방식으로 접근하고 싶습니다. (나는 서버 측에서 nodej를 사용하여 일종의 '가난한 사람의 스트리밍'을 구현하려고 시도하고있다.)

그래서 mp3 프레임 헤더를 충분히 분할해야합니까, 아니면 더해야합니까? (아마도 마지막에 데이터를 추가하여 모든 청크를 '닫는'것일까 요?) '바이트 저장소'는 어떻습니까? 이것이 문제를 일으킬 수 있습니까? 기록을 위해, 저는 현재 128kbps cbr mp3로 작업하고 있습니다. 이렇게하면 어떤 방식 으로든 프로세스가 단순 해 집니까?

decodeAudioData가 vaild 데이터로 기대하는 것에 대한 모든 정보를 제공해 주시면 감사하겠습니다.

감사합니다.

추신 : 나는 이것이 아마도 Fair Dinkum Thinkum의 post에 대한 설명을 요청한 것이지만, 낮은 평판 때문에 의견을 게시하지 못한다는 것을 알고 있습니다. 그래서 나는 그것을 어떻게 할 지 다른 방법으로 볼 수는 없지만 새로운 질문을 던집니다. 다시 한번 감사드립니다.

Answer 1

는 (크롬)에 decodeAudioData 더 실험 후이 내가 찾은 것입니다 :

• 모든 초기 MP3 청크가 성공적으로 오래가 MP3 프레임 경계에 분할로 디코딩됩니다. 일정한 비트율의 mp3에 항상 일정한 크기의 프레임이 포함되는 것은 아니기 때문에 경계가 항상 사소한 것은 아닐 수도 있습니다 (예 : mp3 헤더 파싱 포함). 예를 들어, 128kbps mp3 파일에는 417 바이트 프레임과 418 바이트 프레임이 포함됩니다. (일부 프레임은 패딩으로 여분의 바이트를 포함합니다).
• 임의의 mp3 청크는 이 아니며 '양면'의 정확한 프레임 경계에서 분리 되어도 디코딩이 가능하다는 것을 보장합니다 (). 이러한 종류의 일부 청크는 디코딩 될 수 있지만 다른 청크는 decodeAudioData가 오류를 발생시킵니다. 나는 이것을 mp3 bit reservoir과 관련이 있다고 생각하는데, 이는 mp3 프레임 사이에 의존성을 만든다.

Answer 2

파일을 유효한 MP3 헤더 (바이트 경계에 정렬 된 '1'의 12 비트 : FF Fx)로 시작하는 조각들로 분할하면 대부분 괜찮을 것입니다.