Seeking in VBR MP3 file

[Tuukka Pasanen]

Seeking in mp3 CBR file is very accurate and works fine. Now when lame has default option to VBR level 4 and there is some problems in seeking.
This bug can be reproduced with ffprobe:

./ffprobe -show_frames -read_intervals 42.004898%+1,41.090612%42.031020,40.045714%41.116735 test-VBR4.mp3

Seek times are chosen from normal 'ffprobe -show_frames' without seeking. So playing from begining is working ok. If everything goes fine those PTS should be equal when seeking and when playing from start but now they are not.

[Tuukka Pasanen]

Output this one is from GIT:

ffprobe -show_frames -read_intervals 42.004898%+1,41.090612%42.031020,40.045714%41.116735 ~/Musiikki/Mixxx/bug3095-test-VBR4.mp3 > out
ffprobe version N-57549-g269b3c8 Copyright (c) 2007-2013 the FFmpeg developers
  built on Oct 28 2013 18:21:15 with gcc 4.7 (SUSE Linux)
  configuration: --prefix=/home/tuukka/src/c/ffmpeg-install/ffmpeg-git --enable-shared --disable-static --enable-debug --disable-stripping --extra-cflags= --enable-gpl --enable-x11grab --enable-version3 --enable-pthreads --disable-altivec --enable-libfaac --enable-nonfree --enable-libopenjpeg --enable-avfilter --disable-avfilter --enable-libpulse --enable-libvpx --enable-libass --enable-libass --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libxvid --enable-libx264 --enable-libschroedinger --enable-libgsm --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-postproc --enable-libdc1394 --enable-librtmp --enable-libfreetype --enable-avresample --enable-libvo-aacenc
  libavutil      52. 48.100 / 52. 48.100
  libavcodec     55. 39.100 / 55. 39.100
  libavformat    55. 19.104 / 55. 19.104
  libavdevice    55.  5.100 / 55.  5.100
  libavresample   1.  1.  0 /  1.  1.  0
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mp3, from '/home/tuukka/Musiikki/Mixxx/bug3095-test-VBR4.mp3':
  Duration: 00:09:32.58, start: 0.000000, bitrate: 191 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 191 kb/s
[mp3 @ 0x9a1e20] overread, skip -8 enddists: -6 -6
[mp3 @ 0x9a1e20] overread, skip -7 enddists: -2 -2
[mp3 @ 0x9a1e20] overread, skip -5 enddists: -4 -4

I cutted out frames as they are so large but I'll paste themif needed

[Carl Eugen Hoyos]

Could you confirm that this is a regression since 5864ce13 (ie that it worked fine with 8c51ea54), to some degree related to ticket #2590?

[Tuukka Pasanen]

I think ticket #2590 happens because of the same thing and I was the reason I asked about this.

[Tuukka Pasanen]

Okay I can confirm that '8c51ea54' works ok and '5864ce13' break things.. If there is other way than 'git reset --hard SHASUM' please let me know..

[Michael Niedermayer]

you can use "-usetoc 0" to get the old (slow but accurate) seeking behavior

[Michael Niedermayer]

is there any software that can seek better in this file ? that is seek more accuratly without reading the whole file sequentially

[Tuukka Pasanen]

Replying to michael:

is there any software that can seek better in this file ? that is seek more accuratly without reading the whole file sequentially

Hello I have managed to made little example app for testing this bug for myself in ​https://github.com/illuusio/ffmpeg-example it's very very cruel but you can use it if you want. It tries to simulate Mixxx input plugging as it is my main goal of all this. Mixxx buffers stuff and you can seek backwards (as with vinyls or jump X place in file in DJ set) and the problem with mp3 (everyone’s most loved format) it doesn't sound very well if it's not precise place when you are going backwards or different place in file and play then buffered part.

[Tuukka Pasanen]

Replying to michael:

you can use "-usetoc 0" to get the old (slow but accurate) seeking behavior

This sounds what I want! How do I turn it on?

av_opt_set_int(CodecCtx->priv_data, "usetoc", 1, 0);

doesn't do it.. If I can get speed of pre 1.0 and accurate seeking I'll be on my way..

[Carl Eugen Hoyos]

Replying to tuukka:

av_opt_set_int(CodecCtx->priv_data, "usetoc", 1, 0);

usetoc is a demuxer, not a decoder option, see ffmpeg -h full

[Tuukka Pasanen]

Okay you showed the way but I just can't get clue how to tune it..

        av_opt_set_int(&m_pFormatCtx->iformat->priv_class, "usetoc", 1, 0);

Is this a correct way because if I do this sample_rates are reseted... or should I do this before I open codec?
Edit: If I do right after or before 'avcodec_open2' it works but not making any change

[Tuukka Pasanen]

Ok I can verify this one works ok with code on GIT. So If you want to close this It up to you I can get my code working..

    av_dict_set(&m_iFormatOpts, "usetoc", "0", 0);

    // Open file and make m_pFormatCtx
    if (avformat_open_input(&m_pFormatCtx,filename, NULL, &m_iFormatOpts)!=0) {
        printf("fe_decode_open: cannot open: %s\n",
               filename);
        return -1;
    }

    av_dict_free(&m_iFormatOpts);