12

Lets say one MP3 Frame length in bytes is 104: how to get that in milliseconds? Is there any formula or something to do that?

Mark Heath
  • 48,273
  • 29
  • 137
  • 194
Desolator
  • 22,411
  • 20
  • 73
  • 96
  • 2
    I'd say bitrate is the key. CBR is easiest, VBR will require you to pay attention to rate variations. – sehe Jun 02 '11 at 21:44
  • why do you need this information? – Andrei Jun 02 '11 at 21:52
  • 1
    You don't "need" to do anything! But, usually, when people ask these kind of questions ("how do I get X") they need it for something else. And that "something else" can sometimes be solved differently. – Andrei Jun 02 '11 at 22:09
  • 3
    aha ok.. well I need to crop mp3 file I have.. so I need to set a start time and end time to do the cropping.. I need to calculate the time of every frame in the file.. – Desolator Jun 02 '11 at 22:18
  • You might find the answer here: http://stackoverflow.com/questions/383164/how-to-retrieve-duration-of-mp3-in-net/13269914#13269914 – Daniel Mošmondor Nov 09 '12 at 16:51
  • 2
    @Andrei while that may be true, it's a bad idea to side-step the actual question. I came here wanting to know the exact answer to this exact question. StackOverflow meant to be a public archive of questions and answers to most than just the OP. – Wisteso Oct 24 '17 at 18:16

6 Answers6

27

Hmm, it's strange but no one answer the question properly. I've been investigating, here's the formula:

Frame length (in ms) = (samples per frame / sample rate (in hz)) * 1000

The typical MP3 (an MPEG Layer III, version 1) has 1152 samples per frame and the sample rate is (commonly) 44100 hz. So (1152 / 44100) * 1000 = 26,122449 ms per frame.

Notice the frame length (time) does not depend on the bitrate.

More info: http://www.mp3-converter.com/mp3codec/frames.htm

lucianolev
  • 519
  • 5
  • 5
  • This is should be marked as a correct answer. – jayarjo Oct 20 '19 at 05:58
  • "1152 samples per frame" - is this accurate for VBR? – mvmn Oct 05 '21 at 11:50
  • @mvmn Yes it is, but the number of samples per frame does vary with the sample rate as outlined in Mark's answer. – Paul Sanders Jan 05 '22 at 16:57
  • @PaulSanders The number of samples is the same per frame (1152 in most cases, it can be 576 [half] with different formats). What VBR does is save compressed frames without adding padding. The CBR format is used to stream files at a constant rate (the frame may have N or N + 1 bytes of compressed data—seeking is still possible because you know how many frames use N + 1 bytes. It is constant). – Alexis Wilke Oct 04 '22 at 21:20
  • @AlexisWilke Yes (although I don't think there's any 'N +1'). Just for clarity, there's a distinction to be made between the number of _samples_ per frame (which is, or should be, constant throughout the file) and the number of _bytes_ per frame, which, as you say, for VBR varies (within limits) on a frame-by-frame basis. Like CBR, VBR can (and does) use the 'bit reservoir' to carry any spare bits over to the next frame (and what a horrendous hack _that_ is!). VBR supports seeking by having a primitive form of seek table in the header of the file. I have had to code all this, so I know :( – Paul Sanders Oct 05 '22 at 08:45
  • 1
    @PaulSanders The 'N + 1' is to make sure that you can generate F frames within S bytes total. That way, if you say your file runs at 128Kb, you can make sure to insert exactly 128Kb of data (not one more, not one less byte!). The [documentation](http://www.mp3-tech.org/programmer/frame_header.html) speaks of a padding bit (bit 9) which says "frame is padded with one extra slot" (_slot_ meaning _byte_) and _"[...] As an example: 128kbps 44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long frames [...]". So in there example they mainly have 'N + 1' frames... – Alexis Wilke Oct 05 '22 at 19:50
  • 1
    @AlexisWilke Ah, OK, memory stirs. I wrote that code a long time ago! I see I have the line `fi.pad = (nib >> 1) & 1;`, looks promising. CBR sucks anyway, I never use it for my own files. – Paul Sanders Oct 05 '22 at 22:25
12

You need to parse the MP3 frame header to get the MP3 version and layer number (see this document for the frame header format). Once you have those, you can use the following lookup table to get the number of samples in the frame.

    private static readonly int[,] samplesPerFrame = new int[,] {
        {   // MPEG Version 1
            384,    // Layer1
            1152,   // Layer2
            1152    // Layer3
        },
        {   // MPEG Version 2 & 2.5
            384,    // Layer1
            1152,   // Layer2
            576     // Layer3
        }
    };
Mark Heath
  • 48,273
  • 29
  • 137
  • 194
  • ok.. its MPEG version 1 and the layer is 1152 now where should I add that to get the total time of the frame? – Desolator Jun 02 '11 at 22:54
  • the sample rate can also be found out from the MP3 header. Sample rate is samples per second so number of samples divided by sample rate is the duration of the frame. (can't remember off the top of my head if you have to factor the number of channels in too, I think you do, so for stereo, you would halve the number of samples first) – Mark Heath Jun 02 '11 at 23:02
  • hmm, now I did what you told me but I'm getting "0" always.. here is what I did, "mp3Frame.SampleCount / mp3Frame.SampleRate".. btw, mp3Frame.SampleCount=576 and mp3Frame.SampleRate=11025.. maybe I need to multiply the SampleCount by 2? – Desolator Jun 02 '11 at 23:12
  • You need to use floating point numbers. The frame lasts around 52ms (0.052 seconds). – Mark Heath Jun 03 '11 at 06:15
  • "You need to use floating point numbers" -- or reverse the direction of division and work in frames-per-second rather than seconds-per-frame. – Jules Jun 15 '17 at 00:41
  • @MarkHeath The frames per sample figure applies to each channel, so no, you don't halve it for stereo. So each frame is 26ms. 1,152 samples/frame / 44,100 samples/sec = 0.026 sec/frame. – Gumby The Green Dec 21 '21 at 10:42
0

Frame is not the same as time. BUT if you know the total size you can do something like this overhead+Frame*time=total size.

Mikhail
  • 7,749
  • 11
  • 62
  • 136
  • I have frame length and I have the total length time of the mp3 file.. but I need to somehow get the time of every frame in milliseconds.. for examples if I get 20 mp3 frames I get around 1k milliseconds which means 1 second.. how to accomplish this – Desolator Jun 02 '11 at 21:42
  • http://www.mp3-converter.com/mp3codec/frames.htm FrameSize = 144 * BitRate / (SampleRate + Padding) – Mikhail Jun 03 '11 at 08:40
0

http://en.wikipedia.org/wiki/MP3 has an entry on MP3 file structure but you should try to find one with more details.

The frame header contains a field called bit rate. Given this bit rate and the frame data size you can determine how much actual music time is in that frame data. I expect the formula to be: DataSize = BitRate * TimeInterval.

See http://www.mp3-tech.org/programmer/frame_header.html for details on the bit rate encoding.

Andrei
  • 4,880
  • 23
  • 30
0

I used different approach to calculate the time of every frame in the mp3 file.. assuming that all frames have same size in the file.. so I just get the total time of the mp3 file in milliseconds.. then calculate total frames in the file and finally divide the total time by total frames.. so the formula would look like:

float frameTime = totalTimeMillisec / totalFrames;

you will get the total time of every frame in the track in milliseconds.. after I done that I got around 52 milliseconds... and that was similar to what Mark Heath said..

anyway thanks everybody for the solutions..

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
Desolator
  • 22,411
  • 20
  • 73
  • 96
  • 1
    If it's a MP3 stream, like you want to stream to a media player, and you want to stream in the same rate as the file is playing by delaying each frame. You don't know the total frames (an internet internet radio station will run forever). So the correct answer is a mix of what Mark Heath writes and lucianolev. – nivs1978 Sep 17 '21 at 12:44
-1

Since the data is encrypted you cant know the played bit rate until the data has been decrypted. No one talks how to encrypt (compress) and decompress the data. All i know is the Lame program will take a wave file then filter/resample it then somehow compress the data before placing it within the frames. I dont know if these mp3 players are using 8 or 16 bit words to play in each channel. But the bit rate and all are related to the size of the channel byte and the sample rate played. Not the same as the data first imput to the encoder. How to see the final results which is played by the player is the trick here. CBR makes a good reference from which to later learn VBR.

How does one take 16 bits (WORD per sample) of one sample one channel and compress ot for the MP3 data ? Is the results 12 bits or less ? Whats the compression routine called ?

  • 2
    encrypted? Do you mean compressed? Your answer is a bit confusing. – nalply Oct 10 '12 at 19:45
  • The audio samples are compressed (not encrypted, you don't need a key to decompress the data). Each frame, through, has a header which includes all the information you need to know the size of the frame, the bitrate, framerate, etc. and with that information you can computer the duration of a frame. – Alexis Wilke Oct 04 '22 at 21:15