버퍼사이즈와 ID3퍼싱방법 Helix MP3Decoder

 

요즘은 원만한 디바이스에도 편안한 느낌을 주기 때문에 오디오 및 비디오 코덱 적용이 어렵지 않다.그러나 아직도 펌웨어에서 오디오 코덱을 개발해야 하는 경우가 있어 MP3를 재생하기 위해 Helix MP3Decoder를 퍼팅하여 사용하였다.

https://github.com/ultraem bedded/libhelix-mp3폿팅 방법에 대해서는 그다지 까다롭지는 않고, 인터넷에 샘플 소스가 많아서 찾기도 어렵지 않고 http://www.silabs.com/documents/public/application-notes/an1112-efm32-helix-mp3-decoder.pdf://www.silabs.com/documents/public/application-notes/an1112-efm32-helix-mp3-decoder.pdf문서를 참조하면 좋다. 또 MP3에 관한 좋은 자료를 찾아냈고, 이하의 문서도 정리가 되어 있는 것 같다. https://www.diva-portal.org/smash/get/div a2:830195/FULLTEXT01.pdf 이제부터는 Helix MP3Decoder로 개발 중에 해결한, 아직 궁금한 내용을 정리한다. InputBuffer가 1940인 이유? MP3 인코딩된 데이터는 1frame씩 저장되어 있다. 1프레임씩 읽어서 디코딩한 후, 디코딩할 때, 디코딩할 때, 디코딩할 때

찾아보니 main Data Be gin과 maxn Slots 크기라고 하는데 정확한 설명은 확인되지 않았다. 이것은 후일 갱신할 예정이다. Output 버퍼가 2304인 이유는 MP31 프레임당 1152샘플 데이터를 갖고 있으며 16비트로 처리하기 때문.ID3 퍼싱에 관한 이야기 ID3 는 MP3 파일로 사용하는 메타데이터 포맷이며, 음악의 타이틀, 음악가의 이름 등의 음악 파일에 관련된 정보를 저장한다. 재미있는 것이 MP3는 AAU+Tag 데이터 뭉치로 되어 있지만 ID3는 파일의 맨 앞에 위치한다. "ID3" 3바이트가 있는 00h 오프셋이 ID310바이트 헤더의 시작지점이며, 100h의 FF3으로 시작하는 구간이 MP3AAU 제1 프레임 헤더의 시작이다.

Helix API를 쓴 소스를 보면 다음과 같이 처리되어 있다. READBUF_SIZE(1940) 바이트를 파일로 처음 읽은 후 첫 번째 프레임을 SyncWord(all 11bit'1') 찾는다. 그리고 MP3frameheader를 퍼싱한다.위 그림과 같이 1940바이트 내에 AAU가 있을 경우에는 문제가 되지 않는다.

ID3 헤더의 SIZE 값 0000176을 자릿수당 128씩 곱해서 풀면, (1st byte*0x80)+2rd byte)+3rd byte)+4th byte= 246 이다.기본적으로 여기에서 헤더 길이 10을 더하고, footer 플래그에 의해서 20을 더하지만, 지금은 그다지 중요하지 않다. 어쨌든 246+10=0x100으로, 위에서 100h 오프셋을 보면 AAU 헤더가 보인다.

아래 소스는 MP3를 처음 연 뒤, ID3는 무시하고 첫 번째 프레임을 찾은 뒤 프레임 정보를 퍼싱한다. 다른 소스도 마찬가지이며, ID3이 짧은(1940 버퍼 내에 위치함. . ) 경우 정상적으로 처리되어 재생된다.

그러나 앨범 이미지가 들어가 ID3가 커지는 MP3의 경우 얘기가 달라진다. 아래 MP3 파일을 보면 ID3 사이즈가...((0x30*0x80)+0x42)+0x80+0x3F = C213F, 794,943이 표시된다. 776Kbyte가 넘는다.

15h 오프셋을 보면 FFx라고 되어 있다. Sync Word로 오해될 정도이다. 그러나 프레임 정보가 없기 때문에 에러가 발생한다. 첫 번째 프레임 데이터부터 썸플레이트, 채널 값을 가져와 코덱을 재설정해야 하기 때문이다. 파일을 계속 찾더라도 700K가 넘는 데이터를 일일이 찾아야 하는 문제가 있다.

위에서 계산한 위치를 기반으로 오프셋을 이동하면.. C2149h에 첫 번째 프레임이 나타난다.

그래서 다음과 같이 프로그램을 수정했다. 길이가 짧아도 길이가 정상적으로 재생되는 것을 확인했다.