CODEWITHSUNDEEP
androidaudioandroid-mediaplayer
Normunds Kalnberzins
Normunds Kalnberzins

Reputation: 1245

precision of Android MediaPlayer seekTo

I have a number of mp3 files that I use with Android MediaPlayer to play from certain offsets.

Using seekTo() seems to stop at correct location. player.getCurrrentPosition() returns the correct offset, but in some cases the real position is off for as much as 200 ms. The files are about 3 minutes worth of recording and the incorrect offsets seem to appear at the end. Of some of the files.

I have the same effect either trying with Android 4.0.3 device or 4.3 emulator.

Anybody has experience with "finetuning" MediaPlayer offsets? Any experience why MediaPlayer might not be working correctly with some files? They are all CBR, stereo, some have sampling frequency 22050, some 44100, different bitrates.

I'm setting the offsets from another program and saving to mp3 tags, then in case of doubt verifying manually using Audacity. Audacity agrees with my estimate of what the correct offset is, MediaPlayer seems to disagree.

I'm aware that I could use AudioTrack with raw sound files and have a better control, however it might be impractical as there are many mp3 files, so using raw sound data will make pretty large application or many large data files.

The code is nothing fancy:

player.seekTo(start);
player.start();
CountDownTimer timer = new CountDownTimer(length, 100) {

    @Override
    public void onTick(long millisUntilFinished) {
        if (player!=null) setInt(R.id.nLocation, player.getCurrentPosition());
    }

    @Override
    public void onFinish() {
        if (player!=null) {
            if (player.isPlaying()) {
                player.pause();
            }
            setInt(R.id.nLocation, player.getCurrentPosition());
            player.stop();
            player.release();
            player = null;
        }
    }
};
timer.start();

Upvotes: 2

Views: 1649

Answers (1)

Normunds Kalnberzins
Normunds Kalnberzins

Reputation: 1245

I did not manage to find the rule why the MediaPlayer interprets offset (seekTo) differently for a group of MP3 files. For example when creating a new MP3 file with the same parameters from Audacity+Lame (MPEG1, Layer III, 44100 Hz, 192 Kb/s) it worked perfectly.

However:

  • this can be reproduced - rip MP3 file using Windows Media Player, settings: MP3, 192 kb/s [added when edited]
  • I found the workaround that seems to work for any recording.

The background - in order to tell MediaPlayer to play from certain offset, I store certain data in MP3 tags. I use a separate program to set up the playback (in frames): Label A, start frame=1000, length=100 frames, Label B, start @1500 etc. Now when I need to play it back, I read the MP3 headers, determine the frame length, for example 26.12245 ms/frame and calculate the offset (1000 frames will be 26122 ms).

The workaround is to store in MP3 tag also the frame count and length in ms (or pass through again and count the frames). Then when start MediaPlayer, compare MediaPlayer.getDuration() (MediaPlayer estimate) with the duration stored in MP3 tag. Then adjust the frame size:

adjustedFrameSizeMs = realFrameSizeMs + (player.getDuration()-storedDurationMs)/storedframeCount;

In my case (for the files with incorrect offset) the adjusted frame length always was between 26.08 and 26.09 ms (instead of 26.12245).

I attempted to try see if this is because Android plays the recording quicker (so it estimates the "real time", not the time according to frame size and frame count). It seems that it really does plays quicker. But even quicker than its own estimate. For example a recording of about 1 hour:

  • my estimate: 2448 s
  • MediaPlayer: 2444 s (4 sec difference)
  • Audacity: 2442 s (here we are in disagreement)
  • Foobar: 2448 s (another witness that agrees with my estimate :-)
  • MediaPlayer, real play time: 2438 s

The real playtime was 6 s (0.25%) less than MediaPlayer own estimate. Another attempt on a different sample gave the same percentage difference. However the fact that Audacity and Foobar did not always agree with my estimates, does not let me put all the blame on MediaPlayer.

Upvotes: 2

Related Questions