Seeking issues

[vitamin-caig]

Hello!

There're no way to contact to author, so I have to use bugtracker for that:)

I use my own mpeg stream parser, so minimp3 operates with (offset,size) pairs over the raw data. There's a some problem with mp3dec_decode_frame problem while seeking. It returns 0 samples with proper frame_bytes at the first non-sequential frame decoding. Next call over the same frame also gives the same result. BUT third call works well with glitchy sound at the beginning. Some additional information: 1) there's memset(&scratch, 0, sizeof(scratch)); patch at the beginning of mp3dec_decode_frame - else valgrind warns about unitialized memory usage (but issue is reproduced even without this patch) 2) mp3dec_init is called before non-sequential frame decoding (no change if removed) 3) decoding over several frames' raw data (as recommended in readme) has no any effect

Thank you for any help!

[lieff]

What buffer size available for mp3dec_decode_frame while seeking? 16kb is recommended for proper sync procedure.

[vitamin-caig]

I always feed proper frames, so sync is not required I guess. Anyway, I tried 10 frames window with no luck. Does decoder need to read some information from further frames to fill context?

[lieff]

If you pass exactly 1 demuxed frame there limitation: it must be non free format frame. Can you share this mp3?

[vitamin-caig]

Yes, all the .mp3 files are non-free. E.g. https://github.com/JamesHeinrich/getID3-testfiles/blob/master/ID3v2/ID3v2%20genre%20stored%20without%20parentheses.mp3

Some additional info:

• if I call mp3dec_init before seeking, any next mp3dec_decode_frame fails till called third time (as described)
• if I don't do that, SOME of next mp3dec_decode_frame call fail till called second time

Debugger tells me that L3_restore_reservoir returns false because of main_data_begin != 0 and mp3dec_t::reserv == 0

[lieff]

Yes, it's expected to fail because of bit-reservoir (in mp3 some frame data can be in other frames). Is there any glitchy sound if you call mp3dec_init and ignore failed\without-data frames?

[vitamin-caig]

Yes, there's a glitch. I can implement seeking over key-frames, how could I detect them? I really don't want to ignore failed frames - there're ok really and treated as failed only due to seek process.

[lieff]

"Next call over the same frame" - you must not try decode same frame twice. For correct seek you should start decoding several frames before first data arrived, to be sure that reservoir is filled. The number of frames before should have 511 payload bytes in the worst case to completely fill the reservoir. There no easy way to detect "intra", you must parse beginning of frame to determine if frame uses reservoir and mp3 file may not contain frames that do not use it except first (in fact there many cutted mp3 files that uses reservoir even on first frame, it is not fatal, decoders just skips first frames).

[vitamin-caig]

So, I'm going to 'play' several frames right before required in seek case (so total processed data size will about 1K) and just ignore 0 samples and frame_bytes > 0 case. Will it be enough?

[lieff]

Yep, it should be enough.

[lieff]

Closing due to lack of activity.