0
$\begingroup$

(I don't see a way of conveying the situation better than by providing a screenshot. Please pardon me.)

According to MP3 specs, the below depicted MP3 audio frame starts at 0x00000800, having a length of 0x000001a1, so the next audio frame starts at 0x000009a1.

Yet, loads of sync markers appear in the audio data:

MP3 data


How do I find audio frame boundaries without being required to read the file from the start?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

Sync-word search is a popular technique that is employed in finding the frame boundaries of MP3 file. If the MP3 file is encoded at "constant bit-rate", it is possible to estimate the size of each frame in bytes. As an example consider a 48kHz file encoded at 128Kbps. The framelength of MP3 is 1152(samples) and based on the bit-rate information each second(48000) takes around 16000 bytes. So each encoded frame of MP3 is of length 384 (calculated from $\frac{16000 \times 1152}{48000} $) bytes long. This frame-length information can be to start the next "sync word(0xFFF)" search.

Note: This technique is useful only if the file is encoded in "constant bit-rate" mode and is not applicable if "average bit-rate" encoding is employed. Recommend You to check the wiki page of MP3 for more information on these modes

Improve this answer
$\endgroup$
4
  • $\begingroup$ Thank you, @SakSath, for your reply. I just found at datavoyage.com: "Each value that is specified as reserved, invalid, bad, or not allowed should indicate an invalid header. Remember, this is not enough, frame sync can be easily (and very frequently) found in any binary file. Also it is likely that MPEG file contains garbage on it's beginning which also may contain false sync. Thus, you have to check two or more frames in a row to assure you are really dealing with MPEG audio file." $\endgroup$
    – AxD
    Mar 31 at 11:48
  • $\begingroup$ I also read somewhere else that the audio frame length may not be accurately the same as calculated from the formula. What would be a safe practice to look for the next frame if that frame isn't exactly where it should be? Would a valid approach be to look 1-2 bytes back and forth of the estimated location? Or is it safe to assume that the calculated audio frame length is always right? $\endgroup$
    – AxD
    Mar 31 at 11:50
  • $\begingroup$ Yes the frame length may not be accurately the same as calculated from formula for all bitrates. Hence valid approach would be to look 1-2 bytes back and forth of the estimated location. $\endgroup$
    – SakSath
    Mar 31 at 12:52
  • $\begingroup$ Adding more details on the above approach: Yes the frame length may not be accurately the same as calculated from formula for all bitrates. Hence valid approach would be to consider the floor value of the frame length computed from bitrate - floor((bitrate in bytes) x (frame size) / (sampling rate))and start sync search from there. Again the method is applicable for constant bit-rate mode of encoding. $\endgroup$
    – SakSath
    Mar 31 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.