[FFmpeg-trac] #2877(undetermined:closed): Unable to rewind/seek a mp3

[FFmpeg]

#2877: Unable to rewind/seek a mp3
-------------------------------------+-------------------------------------
             Reporter:  jpo38        |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:  seek         |               Resolution:  invalid
             Blocking:               |               Blocked By:
Analyzed by developer:  1            |  Reproduced by developer:  1
-------------------------------------+-------------------------------------
Changes (by saste):

 * analyzed:  0 => 1
 * status:  new => closed
 * resolution:   => invalid
 * reproduced:  0 => 1


Comment:

 Replying to [comment:11 saste]:
 > Replying to [comment:10 jpo38]:
 [...]
 > > Looks like you read the file twice and you're getting the same number
 of data. It works the same for me, only the data I read (when converted to
 float/double) are not the same....
 > > Did you try to compile my sample? It's very straightforward. It reads
 the file once, rewinds and reads again. It then compares data. We read the
 same number of samples but not the same values...
 >
 > It doesn't explain the issue, but you could try to flush the data in the
 decoder before re-using it in the second loop, since it is the only object
 which is reused between the two sessions. Also, with which formats does it
 happen, how much is the data different, how many samples differ?

 And since I was curious I did a few experiments, and noticed that there is
 a very small imperceptible difference, so the two buffers are different
 but will sound the same to human ears.

 This is apparently how the MP3 decoder (and many other lossy decoders)
 work, they keep an internal state which affects decoding, when you seek
 back and decode again the decoder has a different state, which causes it
 to produce a slightly different output, although no human listener should
 be able to notice the difference.

 In conclusion, it's not a bug in libavcodec but rather the way the MP3
 decoder works. Feel free to reopen the ticket if you don't agree.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2877#comment:12>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker