나는 안드로이드 미디어 플레이어로 mp3 파일을 재생하고 있습니다. 그러나 seekTo (msec) 기능으로 임의의 시간을 검색 할 때 각 안드로이드 장치의 각 플레이어마다 약간의 차이가 있습니다. 시간 차이는 약 1 초입니다.mp3 코덱에도 I/P 프레임이 있습니까?
제가 궁금한 점은 MP3 MPEG1 오디오 코덱에도 I 프레임/P 프레임이 포함되어 있다는 것입니다. 비디오 코덱의 속성이지만 오디오 코덱에도 비슷한 특성이 있는지 알고 싶기 때문에 오디오를 디코딩하기 위해 프레임을 가져 오는 데 필요한 위치로 이동해야합니다. 그렇다면, 각 플레이어가 정확히 동일한 시간에 시작하지 않았기 때문에 그러한 속성이 탐색 시간의 차이를 만들 수 있다는 것이 합리적입니다.
타격의 가능성이 3 가지 문제가 있습니다.
첫 번째는 MP3 프레임 크기입니다. (이것은 비디오 "프레임"과 다릅니다.이 경우 프레임을 MP3로 인코딩 된 샘플로 생각하십시오.) 해당 프레임 크기는 일반적으로 1,152 샘플이됩니다. 당신은 그 레벨 아래에서 탐색 할 수는 있지만 먼저 그 레벨 아래에서 디코딩을해야하며 모든 플레이어가 그렇게하지는 않을 것입니다.
두 번째 문제는 비트 저장소입니다. 프레임은 항상 전체 공간을 필요로하지는 않으며, 인코더는 다른 프레임의 데이터로 다시 채워 넣을 수 있습니다. 일정한 비트 전송률을 유지하면서 더 많은 대역폭을 효과적으로 사용합니다. 순진한 플레이어는 종종 다음 MP3 동기화 단어 (11111111 111xxxxx)를 찾고 거기에서 코덱으로 데이터를 보냅니다. 코덱은 항상 비트 저장소 정보가 누락되어 그 순간에 디코딩해야하는 정보를 보유하지는 않습니다. 그것은 약간의 글리치 사운드를 재생하거나, 충분한 정보가있을 때까지 조용하게 유지할 수 있습니다. 두 가지 행동 모두 야생에 존재합니다.
마지막으로 세 번째 문제는 일반 MP3 파일/스트림에 타임 스탬프 데이터가 없다는 것입니다. 원하는 시크 포인트까지 디코딩하지 않고 파일을 검색하는 것은 추측 일뿐입니다. 효율성을 높이기 위해 플레이어가 자주 수행해야 할 작업은 어디에서 시작해야하는지 추측하여 스트림에 "바늘 떨어 뜨림"을하는 것입니다. 플레이어가 320kbit/s CBR 스트림을 가지고 있고 파일 크기가 얼마나 큰지 알고 있다면 파일이 얼마나 오랫동안 있는지 추측 할 수 있고 균등하게 나누어 원하는 검색 시간의 바이트 오프셋을 얻을 수 있습니다. 상상할 수 있듯이 CBR의 경우에도 이것은 부정확합니다. VBR의 경우 일부 플레이어는 지금까지 보아 왔던 비트율의 평균을 사용합니다. 다른 사람들은 전혀 추구하지 않습니다. 다른 사람들은 첫 번째 프레임을보고 CBR이라고 가정하고 첫 번째 프레임과 동일한 비트율처럼 전체 파일을 처리합니다. (VBR 파일을 때때로 재생하고 파일의 처음 몇 초 동안 끝 타임 스탬프 변경을 확인하십시오. 플레이어가 길이가 얼마인지 추측하고 있기 때문입니다.)