I'm playing mp3 file with Android mediaplayers. But when i do seeking to some random time with seekTo(msec) function, each player in each android device shows slight differences. The difference is in time is about 1 second.
The thing that i am curious about is that Mp3 MPEG1 audio codec also has I frame/p frame stuff? I know it is property of video codec, but i want to know whether audio codec also has similar attribute, so it needs to jump to some position for getting I frame to decode audio. If so , it is reasonable that such attribute can make seeking-time differences, because each player started at not exactly same time.
There are three separate issues you're likely hitting.
The first is the MP3 frame size. (This is different than a video "frame"... just think of frame in this case as a chunk of samples that are encoded into MP3.) That frame size is typically going to be 1,152 samples. You can seek below that level but it requires decoding below that level first out-front, and not all players are going to do that.
The second issue is the bit reservoir. Frames don't always need the entire space, and the encoder can go back and fill them in with data for other frames, effectively using more bandwidth when its needed while staying within a constant bitrate. A naive player will often look for the next MP3 sync word (11111111 111xxxxx) and send data to the codec from there. The codec won't always have the info it needs to decode at that moment due to missing bit reservoir information. It can either play a bit of a glitch sound, or remain silent until it has enough information. Both behaviors exist in the wild.
Finally, the third issue is that a normal MP3 file/stream has no timestamp data in it. Seeking into a file without decoding up to the desired seek point is just guesswork. For efficiency, what players will often do instead is "needle drop" into the stream by guessing where they should start. If the player knows you have a 320 kbit/s CBR stream, and it knows how big the file size is, it can guesstimate how long the file is in time, and simply divide evenly to get the byte offset of the desired seek time. As you can imagine, this is imprecise, even with CBR. For VBR, some players will use the average of the bitrate they've seen thus far. Others won't allow seeking at all. Others will look at the first frame, assume CBR, and will treat the whole file like it's the same bitrate as the first frame. (Play a VBR file sometime and watch the end timestamp change through the first few seconds of the file. That's because the player is guessing as to what the length is.)