• When trying to synchronize the parser against MPEG frame header syncbits, the usual way is to read up until a certain pattern is met (some bit sequence). Then check the bitrate, sampling rate and other options from the header. Then there are two codepath options:
  • If the bitrate is not 'free' calculate the frame length and check to see if there's a MPEG frame sync at the calculated offset (and better do it several times for at least 3 consequent frames to ensure proper synching)
  • If the bitrate is 'free' - find the next MPEG frame sync, check if it is a valid MPEG header and calculate the distance between the synchbit sequences (frame size in bytes), so that the actual 'free' bitrate could be calculated too (and again do it in a loop for at least 3 iterations)

• What is a good behaviour for a code if the bitrate is a fixed value from the table and there's no MPEG frame synch at the calculated offset (broken frame sequence probably)?
• Should i try and find the next frame after the 'garbage' is encountered in a file?
• Is it allowed for MPEG frame sequences to be broken (to include 'garbage' between frames)? What's a good behaviour for the decoder then? In other words, should frames lie one right after another in a file? Is the sequence broken in the other case and the program should abort processing?
• What to do if there's only one or two consequent legal frames in the file (VERY short file) ? is it ok to handle these frames, or is there a minimum size and maximum size requirement a MPEG frame sequence should meet?

• According to the ISO 11172-3 specification:
  Quote

  The all zero value indicates the 'free format' condition, in which a fixed bitrate which does not need to be in the list can be used. Fixed means that a frame contains either N or N+1 slots, depending on the value of the padding bit. The bit_rate_index is an index to a table, which is different for the different Layers.

  
  So, 'free' bitrates can be from 1 bit per second to an infinite value, but must remain constant within all of the frames in the sequence. No restrictions on the bitrate value.
• Next we go to <a href="http://www.mp3-tech.org/programmer/frame_header.html" target="_blank">http://www.mp3-tech.org/programmer/frame_header.html</a> (I'd say it is the most visited site for programmers coding mpeg-related stuff):
  Quote

  "free" means free format. The free bitrate must remain constant, an must be lower than the maximum allowed bitrate. Decoders are not required to support decoding of free bitrate streams.

  
  Again, 'free' bitrate must remain constant, but in this case some restrictions on the value are mentioned - a 'free' bitrate must be less than the maximum allowed bitrate for the certain MPEG version, layer, etc...
• I do not remember the links, but was surfing in search for info and found several board discussions, where it has been said that a 'free' bitrate should fall in the range of minimum and maximum allowed values for current MPEG version, layer, etc...

• Which of the three statements lie and which one is true?
• How do i calculate the actual 'free' bitrate?
• Are there any requirements a 'free' bitrate value should meet (size restrictions)? Please, comment on that.
• What if there's only one MPEG frame with a 'free' bitrate in a short file? How do you determine the frame size in the following cases:
  • It is a short file (one MPEG frame)?
  • A decoder is not ID3v1-aware, and does not recognize appended tags at all - should it read from a short file (one frame) until the EOF is met and consider the whole read data to be a single frame?
• What is a condition to stop frame scanning? Zero bytes encounter? 'Garbage' bytes encounter? Stop, when the maximum frame length (if any) is reached and sync is not met?
• Is the sequence required to include at least two consequent frames with 'free' bitrate for proper parsing?

• First, cut off all the prepended (id3v2, etc...) / appended (lyrics3, id3v1) tags - could parse the tags (that is documented enough), or could just throw the tags away.
   
• Read up to N bytes from the file to a buffer, where N is suitable for most of encoders. This could be 32Kbytes, 64Kbytes or greater (depends on the tolerance of the parser). A value of 32Kbytes is enough, i suppose.
   
• If there's no MPEG frame sync in the first 32Kbytes - this is not a MPEG file, abort the execution.
   
• If a MPEG frame sync is found within the first N bytes:
   
  • If it is not a valid MPEG frame header (validate against allowed combinations of version, layer, sampling rate and other data) - continue searching for the next frame sync
       
  • If it is a valid MPEG frame header - check out the bitrate:
       
    • If it is a fixed value from the table - calculate the size (easily done) and see if there's enough data in the buffer to check for the next synch, otherwise try searching for the next valid MPEG frame header in currently buffered data and calculate the frame size and the bitrate.
           
      • If bitrate is 'free' for the first MPEG frame, and the second MPEG header is not found in the buffered data - we could try to read up to next N bytes and search there (probably, an extremely high bitrate? need to work this out, if there are size limitations on a MPEG frame with a 'free' bitrate). If EOF is reached (or size limit is reached, if exists), and the second MPEG is not found in buffered data - we could abort with 'first N bytes contain an incomplete MPEG frame' message, or consider the whole data to be a single frame and process it as is.
               
      • If bitrate is a fixed tabular value (index from a table) and data is not enough and EOF is not reached, buffer more data until up to size_of_current_frame + 4 consequent bytes are buffered (the size of MPEG frame header is four bytes). If EOF is reached during buffering before all insufficient bytes are read, then we have a broken first frame or a false synch, and the file is quite short, so abort the parsing and report of the incomplete / invalid MPEG sequence.
               
      • If data is enough, repeat checking for at least 3 consequent frames (including the first one), calculating the bitrate and frame size on each iteration (might be a VBR without FHG or LAME VBR header, or 'free' bitrate) and buffering more data if needed:
               
        • If there is only one frame in the buffer, EOF is reached and there was no garbage / zero bytes appended - (the only frame ends up right at the end of the file) - this is a valid MPEG sequence, process the frame as it was the first frame of any legal MPEG frame sequence. If the first frame has 'free' bitrate - we know what to do.
                   
        • If there is only one frame, but with some data after it - check the data. If the four successive  bytes represent a valid MPEG frame header - parse the first frame, but report of the probably incomplete sequence. If the four successive bytes are garbage or zeroes - process the first frame, but report about the garbage at the end of the sequence.
                   
        • If there are two frames in the buffer, EOF is reached and there was no garbage / zero bytes appended - (the second frame ended right at the end of the file) - this is a valid MPEG sequence of two frames, process both. First of all, we check bitrates in both frames. Those should be both 'free', and frame sizes of both frames should be equal in this case. If the first frame is free, and the second one is not - we got a broken sequence ('free' bitrate must remain constant (sizes should also be equal) for all frames) - abort and report. In other cases the frame sizes are well-known (constant or vbr).
                   
        • If there are only two frames with some data after the second frame - check if the succeding data has a valid MPEG frame header following the second frame (incomplete third frame), process the first two frames (and mind the 'free' bitrate validation) and report of a probably broken sequence. If the data after the second frame does not begin with a valid MPEG frame header - process the first two frames (again, remember to check for 'free' bitrates and sizes) and report about the garbage at the end of the sequence.
               
      • If three consequent valid frames are found - we're almost definitely synched. Do parsing.
               
      • If the first frame was of 'free' bitrate all subsequent frames should be of the same 'free' bitrate and size. Otherwise we are dealing with a broken sequence.
               
      • If the first frame is long enough and there's a FHG VBR header present in it - the VBR and duration can be carried out of that header.
               
      • If the first frame is long enough and there's a Xing Tag/Info Tag/LAME header - the VBR/ABR and duration can be carried out of that header.
               
      • If first M frames are all CBR - the whole data is most likely CBR, we can calculate bitrate and duration of the sequence (M can be anything and should also be tuned as a 'tolerance' parameter of the parser, i would propose to set M to 32 or 64 frames - this should be enough, but for those who do not need any optimization, do not care about the parsing time and want a precise calculation - M should be 'all of the frames in sequence')

I'd suggest you to split you post into several small questions, otherwise lazy people (like me) would perhaps not take the time to read your long list of questions.

I'm going to implement this in a day or few in php (can be easily converted to anything else), publish the code and test results here. Meanwhile, i would be glad if anyone in this forum could check and comment on the algorithm, reply on this whole post and answer the questions from the top of this post.

Quote from: Igor Kroitor on 2006-10-25 08:45:16

I'm going to implement this in a day or few in php (can be easily converted to anything else), publish the code and test results here. Meanwhile, i would be glad if anyone in this forum could check and comment on the algorithm, reply on this whole post and answer the questions from the top of this post.

Perhaps the sources of getID3() can be useful for you.
getID3() is a PHP script that extracts useful information from MP3s & other multimedia file formats. It is available under the terms of GNU GPL.

What is a good behaviour for a code if the bitrate is a fixed value from the table and there's no MPEG frame synch at the calculated offset (broken frame sequence probably)?

Should i try and find the next frame after the 'garbage' is encountered in a file?

Is it allowed for MPEG frame sequences to be broken (to include 'garbage' between frames)?

What to do if there's only one or two consequent legal frames in the file (VERY short file) ? is it ok to handle these frames, or is there a minimum size and maximum size requirement a MPEG frame sequence should meet?